Hi Pavel,
So then our transferTo() implementation should be like this?
while ((read = this.read(buffer, 0, TRANSFER_BUFFER_SIZE)) > -1) {
That would then look like the code I used to write…
-Patrick
> Am 14.05.2015 um 00:14 schrieb Pavel Rappo <pavel.ra...@oracle.com>:
>
>
>>>> 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.
>>> It doesn't seem possible as far as I can see. We have 2 methods in
>>> java.nio.channels.Channels:
>>>
>>> newInputStream(java.nio.channels.ReadableByteChannel)
>>> newInputStream(java.nio.channels.AsynchronousByteChannel)
>>>
>>> Neither ReadableByteChannel nor AsynchronousByteChannel is
>>> SelectableChannel.
>>
>> SocketChannel is a subtype of both ReadableByteChannel and SelectableChannel.
>
> Yes, you're right.
>
>>> Sorry, I might be missing something. Anyway, it would be a misbehaving
>>> InputStream as it doesn't conform to the spec.
>>
>> if the read is non-blocking, it can read 0 byte which is conform to the
>> InputStream.read spec,
>> or am i missing something ?
>
> * <p> If <code>len</code> is zero, then no bytes are read and
> * <code>0</code> is returned; otherwise, there is an attempt to read at
> * least one byte. If no byte is available because the stream is at end of
> * file, the value <code>-1</code> is returned; otherwise, at least one
> * byte is read and stored into <code>b</code>.
>
> So as far as I can see, returning 0 as a number of bytes read is not an
> option,
> unless len == 0
>
