Updating existing JDK code to use InputStream.transferTo()

[Remi Forax]

Hi Chris,

On 05/14/2015 12:40 AM, Chris Hegarty wrote:
>
>> On 13 May 2015, at 22:45, Remi Forax <forax at univ-mlv.fr 
>> <mailto:forax at univ-mlv.fr>> wrote:
>>
>>>
>>> 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.
>
> Remi, is this right? I’d have to write a simple test to fully satisfy 
> myself, but ChannelInputStream appears to put a SelectableChannel into 
> blocking mode before reading, if it is non-blocking.

No, it seems, i'm wrong on that.
I have taken a look to ChannelInputStream and 
SocketAdapter.SocketInputStream and both don't accept non-blocking 
SelectableChannel.
Sorry for the noise.

>
>
>> 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.
>
> You are probably right, anything that is not a like for like 
> replacement with the transferTo implementation should have a thorough 
> review from the appropriate component team.
>
> -Chris.

regards,
Rémi