[PATCH] JDK-8054565: FilterOutputStream.close may throw IOException if called twice and underlying flush or close fails

[Nathan Clement]

Hi,

My problem is definitely not related to multi-threaded use.  The test shows basically the same code that we have in production that experienced the problem.  The stream is used from a single thread in a try-with-resources block.

I don't see that this change is any more risky than the change that introduced this bug.  I'm more than happy to have the bug fixed in a different way - this is just the first solution that occurred to me.

Regards,

Nathan

> Subject: Re: [PATCH] JDK-8054565: FilterOutputStream.close may throw IOException if called twice and underlying flush or close fails
> From: pavel.rappo at oracle.com
> Date: Thu, 4 Dec 2014 23:54:10 +0000
> CC: nathan.a.clement at hotmail.com; core-libs-dev at openjdk.java.net
> To: ecki at zusammenkunft.net
> 
> > Hello,
> > 
> > also using a stream in a multi threaded way is quite unusual most of
> > the implementations I have seen use a atomic solution.
> 
> Bernd, as far as I understand we are not talking about concurrent-proof solution
> for the j.i.FilterOutputStream as this class is sure not even thread-safe. Most
> of the subclasses provide their own implementation of close. If they feel they
> should be thread-safe it's their responsibility to support it.
> 
> > Let me add a comment that those stream classes are all heavily
> > overloaded in all parts of code. I think this kind of change is pretty
> > risky (and most people fixed this and other close insanities in the
> > derived methods anyway). Unfortunatelly. (remeber the
> > SupressionException problem?)
> 
> I can’t see why this particular change is risky. We're just trying to make the
> java.io.FilterOutputStream.close obey the java.io.Closeable.close contract.
> 
> -Pavel