On Sat, 19 Nov 2022 16:36:28 GMT, Markus KARG <d...@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. I might be mistaken, but that vector is not temporary: the vector and the enumeration produced from it seems to be reachable for as long as the stream is. Both the enumeration and the vector are synchronized. That synchronization might provide implicit (JMM) visibility for some stream users. ------------- PR: https://git.openjdk.org/jdk/pull/11248
