On Wed, 27 May 2026 10:21:33 GMT, Alan Bateman <[email protected]> wrote:

>> I'm not so much concerned about JDK 1.1 than I am about JDK 25. Notice that 
>> we had already downported and shipped "[JDK-8381670: Revert the changes to 
>> GZIPInputStream related to InputStream.available() 
>> usage](https://bugs.openjdk.org/browse/JDK-8381670)" in our Corretto 25.0.3 
>> release in April and almost instantly got a customer escalation from a huge 
>> client who got affected by the silent drop of concatenated GZIP members. 
>> I've just seen that you have now also backported  
>> "[JDK-8381670](https://bugs.openjdk.org/browse/JDK-8381670)" to Oracle JDK 
>> 25.0.5. Just be aware that this might cause more trouble than it solves.
>> 
>> 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.
>
>> 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?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/30925#discussion_r3311041231

Reply via email to