RFR 8193842: Refactor InputStream-to-OutputStream copy into a utility method
Remi Forax
forax at univ-mlv.fr
Sat Dec 23 23:27:19 UTC 2017
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" <brian.burkhalter at oracle.com>
> À: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> 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
More information about the core-libs-dev
mailing list