Patch to fix BufferedInputStream.skip and bug 4254082

[Christopher Hegarty - Sun Microsystems]

Hi Pascal, Bill, et al,

I was responsible for integrating the contributed fix for 6192696. The 
problem with it was that it relied on a 'good' implementation of the 
available method. By 'good' I mean that it actually returns the amount 
of data that can be read without blocking, and not simply 1. 
ZipInputStream.available simply returns 1 (if there is any data 
available) as it is difficult to determine the amount of available data 
when dynamically uncompressing a data stream.

Now, using available to try and fill as much of BufferedInputStream's 
internal buffer without blocking may result in reading only 1 byte at a 
time from the underlying stream, creating a performance degradation. See
6409506 and 6411870.

I'm not sure what exactly is being proposed here, but if available is 
going to be used to optimize the amount of data actually skipped, be 
aware of the limitation of ZipInputStream.available and other 'bad' 
available implementations.

-Chris.

Pascal S. de Kloe wrote:
> Hello Martin,
> 
>> 6192696: BufferedInputStream.read(byte[], int, int) can block if the
>> entire buffer can't be filled
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6192696
> 
> The problem is fill(). It doesn't check available(). The patch on this 
> mailing list is supposed to fix that too.