RFR JDK-7031075: GZIPInputStream's available() reports 1, but read() gives -1.

[Pavel Rappo]

Now you have to wait for a _R_eviewer, which I'm not. Thanks.

> On 13 Jul 2016, at 18:57, Xueming Shen <xueming.shen at oracle.com> wrote:
> 
> Hi Pavel,
> 
> The test case has been updated accordingly (added GIS and updated
> the "summary" as suggested).
> 
> http://cr.openjdk.java.net/~sherman/7031075/webrev/
> 
> I don't have a strong feeling to against to add inf.needsDirectory()
> for available() to return zero. Just feel it might be better to keep the
> existing behavior if the change does not really solve the problem
> "correctly".
> 
> Thanks,
> Sherman
> 
> On 07/13/2016 02:55 AM, Pavel Rappo wrote:
>>> On 13 Jul 2016, at 00:12, Xueming Shen<xueming.shen at oracle.com>  wrote:
>>> 
>>> (as I commented in the bug report)
>> Sorry, I didn't see this. I should've been more careful.
>> 
>> On other topics.
>> 
>> 1. Original bug refers to GZIPInputStream's behaviour, not InflaterInputStream's.
>> That said, I think it's fair to ask the test to exercise GZIPInputStream.
>> However, it's not mentioned in the test at all. And when I looked into
>> java.util.zip.GZIPInputStream#read I found it has its own (and quite complex)
>> logic and its own eos flag. I wonder if available() should be overridden there
>> as well?
>> 
>> 2. Nitpicking
>> 
>>    * @summary Make sure that the available() methods behave as expected.
>> 
>> Shouldn't it be like this?
>> 
>>    * @summary Make sure that available() method behaves as expected.
>> 
>> 3. We can always return 0 from available(), which is akin to returning the same
>> number from Object.hashCode(). Not a particularly good implementation, but at least
>> a safe one.
>> 
>> Thanks.
>> 
>