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

[Xueming Shen]

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.
>