[kaffe] Problem with BufferedInputStream [patch]

[Mark Wielaard]

Hi,

On Thu, 2003-06-05 at 15:48, Helmer Krämer wrote:
> Just some minor comments, though. If I understand the spec correctly,
> BufferedInputStream.read() should block until data is available and
> read as much of it as possible afterwards (either until the destination
> buffer is full or until further reading from the underlying input
> stream would block again).
> 
> IMHO, simply removing the loop would break this, since without the
> loop you will only read as much data as is already buffered in the
> BufferedInputStream itself, you will not take care of data that might
> be available in the underlying input stream and thus could be read
> without blocking.

The Java Class Libraries (second edition, volume 1) isn't that clear on
the subject. But the online java doc (1.4.2) say:

        This method implements the general contract of the corresponding
        read method of the InputStream class. As an additional
        convenience, it attempts to read as many bytes as possible by
        repeatedly invoking the read method of the underlying stream.
        This iterated read continues until one of the following
        conditions becomes true: 
        
              * The specified number of bytes have been read, 
              * The read method of the underlying stream returns -1,
                indicating end-of-file, or 
              * The available method of the underlying stream returns
                zero, indicating that further input requests would
                block.

> So I would not completely remove the loop, but rather replace it with
> something like "do {} while (len>0 && available()>0)"; dunno whether
> that's really more correct, though...
>
> What do you think?

Seems that is more correct. But since available() isn't that reliable I
wouldn't implement it that way since it might make the method block much
more then needed. See for example the java.util.ZipInputStream
available() method definition (which says to almost always returns 1!).

Also note that the javadoc say:

        Subclasses of this class are encouraged, but not required, to
        attempt to read as many bytes as possible in the same fashion.

So users cannot rely on this behaviour anyway.

Cheers,

Mark