> >> 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. >
Sorry, you are absolutely right, it seems I was somewhere else in my thinking. Just ignore that point :-) >> 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. > This point was not completely clear for me. I thought it, but I was not completely sure about that fact. > 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 I hope there is a change to get that in the JDK9 at the end. I will do as much as I can do from my side though. -Patrick
