On Thu, 9 Jul 2026 14:30:49 GMT, Jaikiran Pai <[email protected]> wrote:
>> [JDK-8385924: GZIPInputStream.read() behaves differently on some Java >> versions](https://bugs.openjdk.org/browse/JDK-8385924) introduced the new >> system property `jdk.util.gzip.tryReadAheadAfterTrailer` which defaults to >> `false` and restores the behavior of `GZIPInputStream` when reading >> multi-member gzip streams to the before-JDK25 (and JDK 27+) state. When the >> property is set to `true`, GZIPInputStream will behave like in JDK 25. >> >> Currently, some of the new `GZIPInputStream` JTreg tests which specifically >> test the non-blocking behavior of `GZIPInputStream` rely on the fact that >> `jdk.util.gzip.tryReadAheadAfterTrailer` is set to `false`. >> >> We should make testing more resilient and allow testing with >> `jdk.util.gzip.tryReadAheadAfterTrailer=true` without errors or timeouts. >> >> Tested with: >> - `make test TEST=test/jdk/java/util/zip/GZIP >> JTREG="OPTIONS=-javaoption:-Djdk.util.gzip.tryReadAheadAfterTrailer=false"` >> - `make test TEST=test/jdk/java/util/zip/GZIP >> JTREG="OPTIONS=-javaoption:-Djdk.util.gzip.tryReadAheadAfterTrailer=true"` >> >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Hello Volker, I'll take a look at this tomorrow. @jaikiran , before you start looking at this PR, I think it needs some redesign, because it doesn't work if we change the default for `jdk.util.gzip.tryReadAheadAfterTrailer` to true` without really setting the system property. The tests need to query ` GZIPInputStream::alwaysReadNextMember` directly instead of reading the system property. I'll send an update shortly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/31790#issuecomment-4936427487
