On Fri, 10 Jul 2026 15:31:48 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 hadn't yet started to review this change and was slightly busy with some > other reviews. So I'll wait for your updates. > > Just a note/question: > >> I think it needs some redesign, because it doesn't work if we change the >> default for jdk.util.gzip.tryReadAheadAfterTrailer to truewithout really >> setting the system property. > > Do you mean a test that expects the JDK to read ahead directly with a call to > `InputStream.read()` even when this property isn't set? Hello @jaikiran, In our next Corretto 25 update release we will restore `GZIPInputStream` to the initial JDK 25 behavior (i.e. to always read the next member). We do this by downporting [8385924: GZIPInputStream.read() behaves differently on some Java versions](https://bugs.openjdk.org/browse/JDK-8385924), but with `GZIPInputStream.alwaysReadNextMember` defaulting to `true`. This prioritizes correctness (and backwards compatibility to the initial JDK 25 release) over performance while still giving users a chance to change the behavior by setting `jdk.util.gzip.tryReadAheadAfterTrailer=false` if they want to. However, if the default for `GZIPInputStream.alwaysReadNextMember` is changed from 'false' to `true`, the tests which test the specific blocking behavior for `jdk.util.gzip.tryReadAheadAfterTrailer=false` will fail in the default configuration, and there's no system property that the tests could check in order to find out that they are running with `alwaysReadNextMember`. So I changed the guards in the tests to directly read `GZIPInputStream.alwaysReadNextMember` instead of relying on the value of the system property `jdk.util.gzip.tryReadAheadAfterTrailer`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/31790#issuecomment-4952082406
