Library enhancement proposal for copying data from/to Reader/Writer InputStream/OutputStream
patrick at reini.net
Fri Dec 5 09:16:53 UTC 2014
>> 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.
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.
More information about the core-libs-dev