Patrick, > Should those methods also be on the FilterInput- and OutputStream?
I'm not sure I'm following you. j.i.FilterInputStream will get the base version of InputStream.copyTo method for free as a child though it doesn't define it itself. Every class down the hierarchy starting from the j.i.InputStream will get InputStream.copyTo version unless it overrides it. To override it, it should of course have some rationale behind it. I believe we have found it for at least two widely used subclasses. > I'm not quit sure about the impact on may already existing customer code that > had implemented such a method without declaring a IOException for example. In > this case the existing code would may break? (as a comment of Alan Bateman > earlier before) In the case you've mentioned everything should be just fine (technically) as overriding method has right to neither throw nor even declare any exceptions thrown by the parent method. I said *technically* because the sole fact of overriding doesn't guarantee the child's method has the same semantics as the parent's one. It seems to me that it’s not the only possible problematic thing here. We'll see. -Pavel
