RFR: 8358456: ZipFile.getInputStream(ZipEntry) throws unspecified IllegalArgumentException

[Jaikiran Pai]

On Tue, 3 Jun 2025 06:35:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8358456?
> 
> In Java 24, through https://bugs.openjdk.org/browse/JDK-8341597 we did a change which started using the "compressed size" field value for computing a input buffer size for the `InflaterInputStream`. The change was reasonable. One part of the change removed a check for  ` <= 0` which would have taken into account invalid/unexpected "compressed size" values:
> From https://github.com/openjdk/jdk/pull/21379
>> There is a check for size <= 0. This condition is unreachable in the current code and in the PR as well, since the compressed size will always be >= 2. I propose we remove this check.
> 
> Without that check, the computed input buffer size can end up being `<= 0` which is an invalid value for a buffer size and thus results in an `IllegalArgumentException` from the `InflaterInputStream` constructor.
> 
> My initial thought was to catch the the `IllegalArgumentException` and rethrow a `ZipException`, but thinking about it, this clearly is more an issue with the value that we computed as an input buffer size. So I believe the right thing here is to reintroduce the check that was previously in place and in such cases just default to reasonable sized buffer. That's what the commit in this PR does. Additionally, I renamed that variable to `inputBufSize` to be clear what this `size` represents.
> 
> A new jtreg test has been introduced which reproduces the issue and verifies the fix. tier testing is currently in progress.
> 
> P.S: As a separate task we might want to do a similar change as what was done in JDK-8341597, to the `ZipFileSystem` code. It currently uses the uncompressed size of the entry to decide the input buffer size.

Hello Eirik,

> Would be interesting to know what kind of tooling produced this invalid/surprising compressed size. The JBS issues does not indicate this from what I can tell.

This was uncovered in tests using ZIP/JAR files created through an internal infrastructure. The tests were validating the exception type being thrown from these APIs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25606#issuecomment-2936020959