Hi Peter, Thanks for the code change suggestion. I have modified the patch to use its logic and to revert to the original boolean instance variable instead of the contentious AtomicBoolean:
http://cr.openjdk.java.net/~bpb/8042377/webrev.02/ The test passes unchanged. Push will be withheld until there’s an imprimatur from a JDK 9 Reviewer. Thanks, Brian On Jun 25, 2015, at 1:31 AM, Peter Levart <peter.lev...@gmail.com> wrote: > Modified code is a little different semantically from try-with resources. in > case both flush() and out.close() throw, try-with resources propagates the > exception thrown from flush() while modified code propagates exception thrown > from out.close(). But that, I think, is actually preferable in this case, > since we are calling method close() on FilterOutputStream. > > The other semantic difference is when flush() and/or out.close() throw > unchecked exception. In try-with-resources case, unchecked exception from > out.close() is always added as suppressed to the exception from flush() while > in modified code, unchecked exception from flush() is ignored when > out.close() also throws. Also, IOExceptio from flush() is ignored if > out.close() throws unchecked exception. Here's how both exceptions can be > considered regardless of whether they are IOException or unchecked: > > public void close() throws IOException { > if (closed.compareAndSet(false, true)) { > Throwable flushException = null; > try { > flush(); > } catch (Throwable e) { > flushException = e; > throw e; > } finally { > if (flushException == null) { > out.close(); > } else { > try { > out.close(); > } catch (Throwable closeException) { > if (flushException != closeException) { > closeException.addSuppressed(flushException); > } > throw closeException; > } > } > } > } > }
