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

[Sergey Bylokhov]

On Wed, 24 Feb 2021 20:48:29 GMT, Phil Race <prr 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.

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