Updating existing JDK code to use InputStream.transferTo()
Remi Forax
forax at univ-mlv.fr
Wed May 13 21:45:10 UTC 2015
On 05/13/2015 05:29 PM, Pavel Rappo wrote:
>> It now can be reviewed as usual at:
>>
>> http://cr.openjdk.java.net/~prappo/8080272/webrev.00/
>>
>> Feel free to review. Thanks.
> Let me start then.
>
> 1. I've seen several cases where current behaviour
>
> while ((n = in.read(buffer)) > 0)
> ~~~
> has been changed to
>
> while ((read = this.read(buffer, 0, TRANSFER_BUFFER_SIZE)) >= 0)
> ~~~
>
> Those things jump out at you, but don't seem to be harmful, since the only case
> where:
>
> java.io.InputStream.read(byte[], int off, int len)
> java.io.InputStream#read(byte[])
>
> may return 0, is when len == 0. And it's never the case here. Unless, of course,
> some misbehaving implementation of InputStream is used.
The other reason to have read that returns 0 is if the underlying
channel is in non-blocking mode.
A read on an InputStream created by Channels.newInputStream on a
SelectableChannel may return 0
and the code will go in a loop until the SelectableChannel can read
something.
while(read() > 0) avoid that issue.
The other things that may be a problem with this patch is that a lot of
codes replaced by transferTo use
either a bigger or a smaller size of buffer than transferTo.
Given that we don't know if the buffer size is something important for a
code or if the buffer size can be changed, i think it's better to split
this patch in several parts and to send each parts to the right mailing
list.
regards,
Rémi
More information about the core-libs-dev
mailing list