RFR 8193842: Refactor InputStream-to-OutputStream copy into a utility method (original) (raw)
Alan Bateman Alan.Bateman at oracle.com
Tue Jan 2 17:01:22 UTC 2018
- Previous message: 回复：RFR: 8194154 patch for crash at File.getCanonicalPath()
- Next message: RFR 8193842: Refactor InputStream-to-OutputStream copy into a utility method
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 22/12/2017 21:51, Brian Burkhalter wrote:
https://bugs.openjdk.java.net/browse/JDK-8194133 http://cr.openjdk.java.net/~bpb/8194133/webrev.00/
Add jdk.internal.io.IOSupport with copy() methods for InputStream-to-OutputStream copying and modify some classes to use these new methods. 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. So not clear to me that Files.copy methods needs to use this.
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.
-Alan.
- Previous message: 回复：RFR: 8194154 patch for crash at File.getCanonicalPath()
- Next message: RFR 8193842: Refactor InputStream-to-OutputStream copy into a utility method
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]