Name: dbT83986 Date: 02/19/99
There seem to be a couple of areas where the behaviour of this function, and requirements on implementations of it, is unclear.
For the abstract class InputStream, the docs say "Returns the number of bytes that can be read (or skipped over) from this input stream without
blocking by the next caller of a method for this input stream." This implies a relationship between the value of available() and subsequent calls to
read(); however this relationship is contradicated by the later statement: "The available method for class InputStream always returns 0", which implies
available() does not always return n > 0 if read() will not block.
I think I understand what you're trying to do here: the idea is that available() is a useful "helper" function which stream clients can use to determine
whether read() might block; however rather than require stream implementors to always provide an implementation of available(), you've decided
to provide a default implementation which returns zero. (It can't do anything more useful because it doesn't know how read() will be implemented.)
That's fine, but it needs to be clearer in the docs. It should specifically be made clear that the user CANNOT, in general, rely on the result of
available() telling him anything that useful about subsequent calls to read(). (Or at least, that a result of zero does NOT imply read() will block or
return -1.)
My second point is that it is not clear how some of the standard InputStream subclasses override available(). It is not clear, for example, whether
FileInputStream provides a useful implementation of the function, or whether it just returns 0 too. By trial-and-error, I've observed that
FileInputStream.available() does indeed appear to always return 0, but it's not clear whether this is a bug, or whether FileInputStream does not
in fact override InputStream.available() (or does, but just invokes the superclass implementation).
(Review ID: 47340)
======================================================================