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

Pavel Rappo pavel.rappo at oracle.com
Wed Jul 13 09:55:54 UTC 2016


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



More information about the core-libs-dev mailing list