On Wed, 24 Feb 2021 20:48:29 GMT, Phil Race <p...@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. The method itself does not close it, but the "try-with-res" around it should. > 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. It read the data in chunks of "8192" bytes. ------------- PR: https://git.openjdk.java.net/jdk/pull/1856
