Name: eaC66865 Date: 01/08/2003


It's difficult to predict the behavior of ReadableByteBuffer.read()
from the APIs, because it says it may return 0, without being
explicit about the conditions under which it will do so.

One condition that isn't stated is that it returns zero if the
buffer is full, even if there are no more bytes in the input
channel. (That may be an implementation bug.
Just filed it, to be sure.)

The other condition that isn't clear is when it says it could
return zero for a non-blocking channel. However, when you create
a buffer using an InputStream, there is no way to tell whether
the implementation is "blocking" or "non-blocking".

InputStream.avaialble() returns the number of bytes that can be
read without blocking. ReadableByteChannel could simply return
that value when it is zero, for a non-blocking implementation.

Or it could invoke InputStream.read(), which blocks until
bytes are available or eof occurs.

So InputStream is neither a "blocking channel" or a non-blocking
one (it appears) -- it can be programmed either way.

That leaves the API reader guesing as to how ReadableByteBuffer
is implemented.

(Helpful dialog with Mark, Mike, Brad, and Jessie have revealed
that when ReadableByteChannel wraps an InputStreams, it's a
blocking channel -- so zero is never returned unless the buffer
is full.)

======================================================================