<Swing Dev> RFR: 8262161 Refactor manual I/O stream copying to new convinient methods in java.desktop

[Phil Race]

On Mon, 21 Dec 2020 07:54:17 GMT, Andrey Turbanov <github.com+741251+turbanoff at 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