On Thu, 28 May 2026 14:24:30 GMT, Alan Bateman <[email protected]> wrote:
>> 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. Thanks you all for your support! This sounds like a reasonable plan to me. How do you plan to solve point "3. For JDK 27, introduce a system property..."? Do you want to do this with the initial fix for [JDK-7036144](https://bugs.openjdk.org/browse/JDK-7036144), by wrapping the input stream and overriding available() or in a completely different way? It's also just a week away from Rampdown Phase One for JDK 27, so we have to hurry up. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30925#discussion_r3319258726
