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