BufferedInputStream should override transferTo

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 BufferedInputStream. As it is a common pattern told by many Java tutorials, lots of existing applications do wrap FileInputStream using BufferedInputStream by default. Hence, many existing applications will not experience the offloading-improvements made by JDK 18.

To provide enhanced performance to existing applications, it makes sense to address this impediment: BufferedInputStream.transferTo should be implemented in a way that first writes the complete buffer content to the target output stream, then command the wrapped input stream to directly transfertTo(out) on its own.

JMH benchmarking with an initial prototype has proven this to be simple yet effective:

Java 19-internal without patch
BufferedReaderPerformanceTest.buffered_transferTo thrpt 25 0,624 ┬▒ 0,043 ops/s
BufferedReaderPerformanceTest.unbuffered_transferTo thrpt 25 0,855 ┬▒ 0,135 ops/s
Java 19-internal with patch
BufferedReaderPerformanceTest.buffered_transferTo thrpt 25 0,930 ┬▒ 0,139 ops/s
BufferedReaderPerformanceTest.unbuffered_transferTo thrpt 25 0,946 ┬▒ 0,124 ops/s

As these numbers demonstrate, the original (unpatched) code of JDK 19-internal shows a clear difference between using and not using BufferedInputStream, where the buffer seems to eat up lots of execution time (which certainly is exactly the opposite of what the application programmer wants to reach by using a buffer), while the modified (patched) code shows rather same performance between using and not using a BufferedInputStream. This proofs that the patch is effective and frees lots of otherwise squandered ops/s.