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