7015589: (spec) BufferedWriter.close leaves stream open if close of underlying Writer fails

[Mike Duigou]

This change looks good. I don't believe a compatibility switch for the FilterOutputStream is warranted.

On Aug 9 2011, at 04: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