NIO! Nein!

java-programmer, NIO! Nein! I recently had the misfortune of trying out a InputStream.available()
command, only to find out it doesn't work on sockets.

I've found that the solution to my problem is the Nio SocketChannel
class, and now I have only one question:

What was Sun smoking when they came up with SocketChannel and where can
I get some?

SocketChannel* and the SSLEngine is probably the most complicated way of
doing socket work and I can only wonder whose crazy idea it was.

Why couldn't they just make .available() work as advertised?

*sigh*

Just wanted to publically complain about unncessary complication.

java-programmer >> NIO! Nein! EdwardH wrote:
> I recently had the misfortune of trying out a InputStream.available()
> command, only to find out it doesn't work on sockets.
>
> I've found that the solution to my problem is the Nio SocketChannel
> class, and now I have only one question:
>
> What was Sun smoking when they came up with SocketChannel and where can
> I get some?
>
> SocketChannel* and the SSLEngine is probably the most complicated way of
> doing socket work and I can only wonder whose crazy idea it was.
>
> Why couldn't they just make .available() work as advertised?
>
> *sigh*
>
> Just wanted to publically complain about unncessary complication.

What were you expecting available() to do? Many people read more into
its specification than is actually guaranteed.

Mark Thornton

java-programmer >> NIO! Nein! > What were you expecting available() to do? Many people read more into
> its specification than is actually guaranteed.

Tell me if there are any bytes waiting in the socket buffer.

It always returns falls.

So does ready().

java-programmer >> NIO! Nein! EdwardH wrote:
>>What were you expecting available() to do?
>
> Tell me if there are any bytes waiting in the socket buffer.

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

> It always returns falls.

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.

java-programmer >> NIO! Nein! EdwardH wrote:

> I recently had the misfortune of trying out a InputStream.available()
> command, only to find out it doesn't work on sockets.

Never use available().

It doesn't do what most programmers think. If there are /any/ valid (safe and
correct) uses of it, I have yet to hear of them.

Never use available().

-- chris

java-programmer >> NIO! Nein! Chris Uppal wrote:
> Never use available().
>
> It doesn't do what most programmers think. If there are /any/ valid (safe and
> correct) uses of it, I have yet to hear of them.
>
> Never use available().

It's used by java.io.BufferedinputStream.read to see if fill any more of
its buffer without blocking.

For a brief time mustang had a peabody fix that tried harder to fill the
buffer. Unfortunately, for some streams available will often return 1.
If you try to read exactly the amount returned by available, that can
result in a vastly increased number of read (and available) calls,
killing performance.

Tom Hawtin
--
Unemployed English Java programmer
http://jroller.com/page/tackline/

java-programmer >> NIO! Nein! Thomas Hawtin wrote:

[me:]
> > It doesn't do what most programmers think. If there are /any/ valid
> > (safe and correct) uses of it, I have yet to hear of them.
>
> It's used by java.io.BufferedinputStream.read to see if fill any more of
> its buffer without blocking.

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

-- chris

java-programmer >> NIO! Nein!
"EdwardH" <edwardh@N:O:S:P:A:M:edward.dyndns.org> wrote in message
news:X5Yng.6417$email***@***.com...
>> What were you expecting available() to do? Many people read more into
>> its specification than is actually guaranteed.
>
> Tell me if there are any bytes waiting in the socket buffer.
>
> It always returns falls.
>
> So does ready().

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

java-programmer >> NIO! Nein! EdwardH wrote:
>>What were you expecting available() to do? Many people read more into
>>its specification than is actually guaranteed.
>
>
> Tell me if there are any bytes waiting in the socket buffer.
>
> It always returns falls.
>
> So does ready().

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