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