Available() - Don't use it!!!!!!

Question

I've seen a number of questions and replies recently where the InputStream.available() method, also inherited by many subclasses, is being used, or where the replies advise that it be used.
So far, I haven't seen a single usage which is correct.
Unless you're doing asynchronous I/O (java.nio...), it's very unlikely that this method is going to do what you want. All it tells you is how many bytes (not strings, or objects, or whatever, just bytes) can be read without the stream blocking (making the calling thread wait). It has nothing to do with the number of bytes that will ultimately be readable from the stream. It is not the size of the file.
In short, unless you have a clear understanding of asynchronous I/O your use of this method is almost certainly going to be wrong.
Sylvia.

Answer 1

>>>
Pretty obvious if the file is more then 2Gb.
So if the file is more than 2 gigs than a read will
block?
I know I can write C code for files larger than that
and the read will not block.
So why does java have this limitation?I don't understand the point you're making. The
available() method was never required to return a
number such that an attempt to read more than that
number would definitely block. That requirement would
be absurd, because the read() must necessarily folllow
the call to available() and in the mean time, more
data may arrive, so that a read of more bytes that
were supposedly available will still not block.
So for a file greater than 2Gb, it would be reasonable
for the available() method to return values lesss than
2Gb. This would be in compliance with the
specification.
Nope. The docs state quite clearly that it returns the number of bytes that can be read before a block occurs.
It doesn't say anything about returning a value less than what might be available before a block.
And we are not discussing what is "reasonable" but rather exactly what the specification says.
Of course if you wish to discuss what is reasonable then please provide an example of code that does not return the file size. Because I consider it reasonable (given my knowledge of how low level file systems work) that the only reasonable size to return is the size of the file.
>>
What about a file on a network file system?
Irrelavent. All current file systems mount files at
the OS level. The file size will be the same
regardless of whether it is local or not.But the implication is that if available() returned
the size of the file, then reads of that amount of
data could block because the system has to wait while
further data arrives over the network. In such
situation, available() would not be conforming with
its specification.And again that is not the point.
The point is not whether blocks occur but rather whether any OS provides that information at the low level (much less high level) io calls for a file system read.
As far as I know they do not.
And unless a 'magic' interface has been added to java or it is replacing the OS itself then it is not going to have that information.
>
>>
The documentation itself for available() in
FileInputStream says :
"Returns the number of bytes that can be read from
this file input stream without blocking."
And when the file is bigger than 2 gigs but it can
read the file without blocking what does it return?
It can't return 2 gigs because that is a lie.No - it's simply saying that you can read that many
bytes without blocking.And as I already pointed out I can read more than that on any OS that I know of without blocking.
>
And it can't return more than that because the int is
too small.
And it can't return less than that because that would
be a lie as well.
So in the above case which of the following are you
claiming?
1. The documentation is wrong.
2. Files bigger than 2 gigs are not allowed.Neither, for the reasons stated above.You are claiming that the value returned represents a blocked value. And I am specifically telling you that that does not happen at the OS level. So exactly what are you claiming is blocking?
>
>>
It would be nonsense to talk about blocking if the
only possible case for blocking was where an attempt
was made to read more bytes than are in the file,
because an attempt to read more bytes than that would
still not block. It would read up to the end of file
and return immediately.No idea what you are talking about.
Whether I can produce an example is irrelevant. This
is about specification, not about current
implementations.So you claim that the documentation is now and always
will be perfect?I claim that it is correct. And you know this because?
I can only presume that either you have verified it in java or you have verified it with the low level io calls for a particular OS.
Which one is it? And if the latter please provide the OS and hopefully a link so I can read about this low level io block.
In view of this
discussion, and other people's misunderstandings, I
think the documentation could be improved to make it
clear that it cannot be infered that an attempt to
read more than available() returns will necessarily
block. Although as I've argued, that should have been
obvious.And as I was trying to make obvious, for the context I gave, it will not block and thus the only reasonable size that available can return, based on the documentation, is the size of the file.
>>
And whether you can produce an example is relevant to
me.
Because it is rather easy for me to produce an example
of an InputStream that will block and thus your
comment about InputStream.available() seems very
relevant.
However, I can't conceive of a situation (given the
constraints that I suggested and that normally occur)
where a file read will block. I know for a fact that
OS file system implementations do not do that.
Blockage does occur but that information is not
available to the low level file io methods.This should be viewed as a limitation in current O/S
implementations. There's no good reason for a system
not to support asynchronous disk I/O, and certainly no
such reason for a failure to support it on network
file systems.There is a very good reason for it. The OS itself does not expect it. And given that every modern 32 bit and 64 bit system that I know of does it exactly that way I don't really expect it to change in the future.
However, feel free though to provide a link to a research paper, or several, that demonstrate that we can expect to see this in the next wave of hard drives or file systems.