No, it tells you *how many* if any, as an integer.

You mean zero? Actually Socket.getInputStream().available() works as
advertised, and so does Reader.ready() if you wrap a Reader around a
socket input stream.

I think you must mean that available() always returns *zero* for
*SSLSockets*, which is basically because it can't be implemented
rationally without encountering the very block it is intended to avoid
(because you might only have read half the next SSL record so you'd have
to read the rest of it to find out how long it was, so you'd block--and
decrypt, which adds even more to the overhead).

It would help if this was documented. However as there are practically
no valid uses for available, or at least none that I've ever
encountered, it's not such a great loss really.

   The available() method returns an int, not a boolean:
http://java.sun.com/j2se/1.5.0/docs/api/java/io/InputStream.html#available()

   It returns the number of bytes that can be read without blocking the
next call. When it doesn't know, it is conversative (reporting less than the
real number of bytes). Thus, if it always returns 0, it is fulfilling its
adervtised contract.

   Similarly for ready().

   - Oliver

All it guarantees is that if it returns a number greater than zero, then
you can read that many bytes without blocking. It is legitimate for
available to always return zero. That is it is a lower bound on the
number of bytes which can be read without blocking.

Mark Thornton

[me:]

So it is.  Part of the contract too (which I hadn't noticed either).  Seems
pretty daft...

   -- chris