RFR JDK-7031075: GZIPInputStream's available() reports 1, but read() gives -1.
xueming.shen at oracle.com
Wed Jul 13 21:54:16 UTC 2016
webrev has been updated to use jdk.testlibrary.RandomFactory to
create the Random object for the test case, as Brian suggested.
On 07/13/2016 11:42 AM, Pavel Rappo wrote:
> 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).
>> 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
>> 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.
More information about the core-libs-dev