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

[Vitaly Davidovich]

But where does it say that this class can be used in a concurrent context?
This class is documented as serving a base class role, yes, but it has
state.  It's the user/subclass responsibility to provide threadsafety, as
far as I see.  Attempting to make close() atomic just makes the next reader
confused when the rest of the class isn't and may also penalize single
threaded callers of close().

If someone were using this class in a non threadsafe manner when safety is
needed, it's no different than one using, say, HashMap unsafely and simply
getting lucky all this time.

Sent from my phone
On Dec 4, 2014 7:58 PM, "Bernd Eckenfels" <ecki at zusammenkunft.net> wrote:

> Am Thu, 4 Dec 2014 23:54:10 +0000
> schrieb Pavel Rappo <pavel.rappo at oracle.com>:
>
> > 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.
>
> It is used very much, also in concurrent context. As I explained the
> close() operation is very likely to happen in different threads
> (especially in situation where it is called multiple times in addition
> to the regular close of the using thread). Thats why I think it might
> be a good idea to make this function thread safe.
>
> > 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.
>
> Well, it changes the behavior of all custom classes which extend
> FilterStream (and since this was a base class made to be extended,
> there are many). For example if somebody depends on getting an error on
> close() from a wrapped stream even when close is called multiple times
> (by timeout thread) you will no longer get that error but a clean
> return of the second attempt.
>
> It might not be spec compliant to rely on this. But my own experience
> is I modified lots of minor details of the FilterOutputStream in
> overwritten methods by first inspecting the implementation. And I cant
> be the only one.
>
> Gruss
> Bernd
>