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" <e...@zusammenkunft.net> wrote: > Am Thu, 4 Dec 2014 23:54:10 +0000 > schrieb Pavel Rappo <pavel.ra...@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 >
