Hi Brian, it's not clear to me that all internal usages should use IOSupport.copy and not InputStream.transferTo, a specific InputStream implementation (like DataInputStream) may come with a more optimized version of transferTo.
It remember me Collections.sort()/List.sort(), at first it was decided that List.sort() should call Collections.sort() but after thinking a little bit more, Collections.sort() was re-written to call List.sort() because it may use faster implementation (like ArrayList.sort()). cheers, Rémi ----- Mail original ----- > De: "Brian Burkhalter" <[email protected]> > À: "core-libs-dev" <[email protected]> > Envoyé: Vendredi 22 Décembre 2017 22:51:17 > Objet: RFR 8193842: Refactor InputStream-to-OutputStream copy into a utility > method > 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. > > Thanks, > > Brian
