I see that CR 7015589 was integrated into JDK8 b04.
-Chris.
On 09/22/11 09:40 AM, Jing Lv wrote:
Hi Alan,
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 [1] 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:
http://cr.openjdk.java.net/~alanb/7015589/webrev/
Thanks,
Alan.
[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-January/005732.html
