On Mon, 21 Dec 2020 07:54:17 GMT, Andrey Turbanov <github.com+741251+turban...@openjdk.org> wrote:
> Cleanup code to use new handy methods in > `java.io.InputStream`/`java.nio.file.Files` instead of manual stream copy: > 1. java.io.InputStream#readAllBytes > 2. java.io.InputStream#transferTo > 3. java.nio.file.Files#copy > > Similar issue - https://bugs.openjdk.java.net/browse/JDK-8080272 src/java.desktop/unix/classes/sun/print/UnixPrintJob.java line 601: > 599: try (BufferedInputStream bin = new > BufferedInputStream(instream); > 600: BufferedOutputStream bout = new > BufferedOutputStream(output)) { > 601: bin.transferTo(bout); https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/io/InputStream.html#transferTo(java.io.OutputStream) This method does not close either stream. --- So this doesn't look right. src/java.desktop/share/classes/com/sun/media/sound/DLSSoundbank.java line 990: > 988: AudioInputStream stream = AudioSystem.getAudioInputStream( > 989: audioformat, (AudioInputStream)sample.getData()); > 990: stream.transferTo(data_chunk); Are all these audio streams buffered ? transferTo docs don't say anything in terms of guarantees of what API they call. If it is unbuffered and it just calls read(byte) over and over it would be really slow. ------------- PR: https://git.openjdk.java.net/jdk/pull/1856
