On Wed, 27 May 2026 13:24:22 GMT, Volker Simonis <[email protected]> wrote:
>>> I'm also not so much concerned about JDK 27, so although I disagree with >>> this PR, I don't think it will create a lot of harm because nobody will >>> using it in production anyway. We still have enough time to fix this until >>> the next LTS will be released, but I **strongly** advocate for a solution >>> that can be downported to JDK 17, 21 and 25 as well. >> >> Our focus has to be forward looking. If fixing the issue with streams that >> contain a series of members, in conjunction with an underlying stream that >> doesn't have a useful available() implementation, can't be fixed without >> behavioural compatibility issues then we have the option of deprecating the >> existing constructors, and adding a new constructor or factory method. >> >> The backports are unfortunate but should not be our focus right now. It >> might be that they need a system property or some knob to deal with the >> issue on JDK 25u at least. > > JDK 25u is especially sensitive here, because JDK 25 was released with the > fix for [JDK-7036144](https://bugs.openjdk.org/browse/JDK-7036144). As I > wrote, we got complains after backing it out, so we will most probably leave > it in our 25u releases. > > I also thought about using properties to control the behavior. It might be > good if we could agree on a common property for Oracle, OpenJDK and > VendorJDKs especially when it comes to downports. > > One simple solution might be to wrap the incoming `InputStream` into another > `InputStream` which overrides `available()` to make sure it doesn't return > `0` if there are more bytes to read. This wrapping could be controlled by a > system property. What do you think? Jai, Lance and I met today to go over the issues with GZIPInputStream. Here's a summary of where we got to: 1. For JDK 28 or later, introduce a new constructor to create a GZIPInputStream that works like it should have done in JDK 1.1 when the API was originally introduced. We discussed two possible sets of parameters. We also discussed maybe deprecating the two existing constructors due to the issue of treating available==0 as EOF and the issue of swallowing exceptions. 2. For JDK 27 or later, replace the class description as per the current proposal. We can drop the spec update for the read method. The issue of an I/O exception when reading beyond a trailer is problematic too so that might have to be removed from the current wording. 3. For JDK 27, introduce a system property that controls the reliable handling of streams with more than one member. Long standing behavior does not handle the case where the underlying stream doesn't have a useful avaialble() method and it additionally swallows any exception when reading ahead. The system property can be documented as an implNote in the 2-arg constructor or class description. The property will need default to long standing behavior (not the more recent/changed behavior). 4. JDK 25u, system property to control behavior could be back ported to align with 27. We understand the OpenJDK updates project has back ported JDK-7036144 to other releases but we did not discuss this. 5. Expand the test coverage. It's always risky to change something in code from JDK 1.0/1.1 so having tests that capture the current behavior (even if unspecified) is important before making any change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30925#discussion_r3318466104
