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

[Xueming Shen]

On 7/12/16, 3:40 PM, Pavel Rappo wrote:
>> On 12 Jul 2016, at 23:38, Pavel Rappo<pavel.rappo at oracle.com>  wrote:
>>
>> Hi Sherman,
>>
>> A quick question. Is "inf.finished()" the only condition that needs to be
>> checked in order to determine reachEOF? In read(), for instance, they use union:
>>
>>     if (inf.finished() || inf.needsDictionary())
>>         reachEOF = true;
>>
>> Otherwise it seems to me it could be the case that read() returns -1 while
>> available() returns 0.
> Sorry, available() returns 1.
>
>> Or I am missing something obvious.

Hi Pavel, thanks for looking into it.

inf.finished() == true is the situation that the inflater really hits the
end of the compressed stream.

inf.needsDictionary() actually means you can't read more bytes from
the inflater if you don't update/feed a directory, not a real "the eof
has been reached".

Yes, the InflaterInputStream.read() will still return -1 and available() 
will
returns 1, if it's the situation that inf.needsDictionary() is true. My
original thought (as I commented in the bug report) was to include
both in the changeset, but then I'm concerned that these might be
actually two different things. The spec says "returns 0 after EOF has
been reached ...", but arguably inf.needsDictionary() is not a real
EOF, class that extends IIS, or the anyone that holds a reference to
the inflater CAN explicitly check inflater and in theory can continue
the read the stream. I'm not sure if anyone is really doing that
though. So I decided to limit the change to the real issue (reach
the end of stream, as showed in the test case) in this changeset. I
am not sure the best solution for the inf.needsDictionary() case for
now, maybe leave it for now until there is a real use case.

Sherman