> 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
