RFR 8193842: Refactor InputStream-to-OutputStream copy into a utility method (original) (raw)

Brian Burkhalter brian.burkhalter at oracle.com
Tue Jan 2 23:43:57 UTC 2018

On Jan 2, 2018, at 9:01 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

One thing that I noticed when looking at this is that in the fix for https://bugs.openjdk.java.net/browse/JDK-8193842, the Files.copy() method had a loop like

while ((n = read(…)) > 0) whereas InputStream.transferTo() had while((n = read(…)) >= 0) which is to say that Files.copy() would terminate if there were an empty read() but transferTo() would not. The patch for 8193842 therefore possibly introduced a subtle behavioral change which no one noticed. read(byte[]) is blocking so it should only return 0 if called with a 0-length array.

Good point so “>” should be used.

So not clear to me that Files.copy methods needs to use this.

So you are suggesting leaving the call to InputStream.transferTo() in preference to IOSupport.copy()?

For JrtPath then the code is specific to the jimage -> jimage case. I think that can be left along too or just replaced with a better implementation for jrtfs.

It would simplify this patch a little to leave this part out.

Brian

More information about the core-libs-dev mailing list