On Mon, 6 Jul 2026 14:28:54 GMT, Volker Simonis <[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? ------------- PR Comment: https://git.openjdk.org/jdk/pull/31790#issuecomment-4936909549
