Updating existing JDK code to use InputStream.transferTo() (original) (raw)

Remi Forax forax at univ-mlv.fr
Wed May 13 23:07:31 UTC 2015

Hi Pavel,

On 05/14/2015 12:14 AM, Pavel Rappo wrote:

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 ? *

If len is zero, then no bytes are read and

* 0 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 -1 is returned; otherwise, at least one * byte is read and stored into b. So as far as I can see, returning 0 as a number of bytes read is not an option, unless len == 0

Yes, you're right, my bad on that.

Rémi

More information about the core-libs-dev mailing list