On Sun, 20 Nov 2022 07:45:11 GMT, Alan Bateman <al...@openjdk.org> wrote:
>> Since JDK 18 some implementations of InputStream.transferTo, namely
>> FileInputStream and ChannelInputStream, offload work to lower layers using
>> NIO channels. This provides shorter execution time and reduced resource
>> consumption. Unfortunately, this effect is prevented once the input stream
>> itself is wrapped by a SequenceInputStream. While compared to other
>> InputStreams the SequenceInputStream is a rather edge case (e. g. used to
>> merge two files into one), nevertheless it makes sense to get rid of this
>> obstacle simply by implementing transferTo (e. g. by allowing to offload the
>> file merge, or parts of the file merge, to the operating system). As a
>> result, more existing applications will experience the
>> offloading-improvements made by JDK 18.
>>
>> To provide enhanced performance to existing applications, it makes sense to
>> address this impediment: SequenceInputStream.transferTo should be
>> implemented in a way that iteratively calls transferTo on each enumerated
>> InputStream of the SequenceInputStream in ordered sequence.
>
> src/java.base/share/classes/java/io/SequenceInputStream.java line 245:
>
>> 243: public long transferTo(OutputStream out) throws IOException {
>> 244: Objects.requireNonNull(out, "out");
>> 245: if (getClass() == SequenceInputStream.class) {
>
> For BIS we had to restrict optimizations to direct usages because that class
> exposes its internals to subclasses via protected fields. We don't have this
> with SIS. On the other hand, SIS is non-final, dates from JDK 1.0, so we have
> to assume there are "transferTo unaware" subclasses that override the read
> methods to intercept all access. So I think being conservative and checking
> for subclassing is right. It doesn't prevent it being relaxed in the future.
Exactly what I had in mind when authoring this code change. :-)
-------------
PR: https://git.openjdk.org/jdk/pull/11248
