On Sun, 12 Jul 2026 17:22:44 GMT, Volker Simonis <[email protected]> wrote:

>> 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`.

@simonis Is this change really needed in main line or is this so that the tests 
pass with the changes in Corretto 25u? I'm wondering if this is really a change 
for jdk25u.

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

PR Comment: https://git.openjdk.org/jdk/pull/31790#issuecomment-5024984348

Reply via email to