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
