7015589: (spec) BufferedWriter.close leaves stream open if close of underlying Writer fails
lvjing at linux.vnet.ibm.com
Thu Sep 22 08:40:14 UTC 2011
I see the status of 7015589 has changed to "fix delivered", so
is this fix in the repository(java8?) already?
On 2011/8/9 19:43, Alan Bateman wrote:
> A few months back there was a bug report  pointing out that it's
> possible to continue writing to a BufferedWriter after invoking its
> close method and the close fails. A similar issue arises with
> BufferedOutputStream and other classes. At issue is whether a stream
> (or more generally a resource) is considered closed in the event that
> the close method fails. This isn't something that Closeable is clear
> on. Joe tells me that this didn't come up in the Coin discussions on
> try-with-resources either.
> I think it's safe to say that it would be desirable that close
> releases the resources for failing cases as otherwise the resources
> may never be released (esp. with try-with-resources usages).
> Furthermore, when there are multiple resources involved, or cases like
> the bug report where one stream wraps another, then it would be
> desirable to keep the state of the resources in sync. To that end, the
> changes here propose adding an advisory note to AutoCloseable to
> advise implementers to release the underlying resources and to mark
> the resource as closed prior to throwing the exception.
> For the specific buffering classes discussed at the time, these are
> changed to follow this advise (but their javadoc isn't changed as
> there may be other implementations or these classes extended in many
> ways). In the case of BufferedWriter it is also fixed so that any
> exception from flushing the underlying writer isn't supplanted by the
> exception from close. In the case of FilterOutputStream
> (BufferedOutputStream extends it) then it is fixed so that it doesn't
> ignore the exception thrown when flushing the underlying stream. This
> is clearly the right thing to do but it does mean that close can now
> throw an IOException for a case where it didn't before. For now I
> don't propose to include a compatibility switch but this may be
> something that has to revisited later. There are other classes in
> java.io that could also be cleaned up but I don't propose to do a
> complete audit at this time.
> The webrev with the changes is here:
More information about the core-libs-dev