Library enhancement proposal for copying data from/to Reader/Writer InputStream/OutputStream

[Patrick Reinhart]

> 
>> 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