RFR: JDK-8297298 - SequenceInputStream should override transferTo

[Alan Bateman]

On Sat, 19 Nov 2022 16:36:28 GMT, Markus KARG <duke at 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.

-------------

PR: https://git.openjdk.org/jdk/pull/11248