RFR 8193842: Refactor InputStream-to-OutputStream copy into a utility method
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.
More information about the core-libs-dev