On Tue, 26 May 2026 17:32:23 GMT, Alan Bateman <[email protected]> wrote:
>>> I think everyone involved understands this. >> >> If by "*everyone involved*" you mean the people working on this PR I agree, >> however if you mean the users of `GZIPInputStream` I completely disagree. >> >>> There is work required to find a solution that does not impact existing >>> usages. We can't rule out deprecating the existing constructors. >> >> I understand, but that doesn't explain (at least to me) why it seems >> acceptable to you to backout a correctness fix in favor of fixing a >> performance regression and at the same time are so hesitant to explicitly >> mention the correctness issue in the documentation? > >> If by "_everyone involved_" you mean the people working on this PR I agree > > I mean everyone involved in the current cluster of issues. > >> I understand, but that doesn't explain (at least to me) why it seems >> acceptable to you to backout a correctness fix in favor of fixing a >> performance regression and at the same time are so hesitant to explicitly >> mention the correctness issue in the documentation? > > GZIPInputStream dates from JDK 1.1 so close to 30 years of existing usage. We > have to be super cautious with changes as we have no idea what might be > depending on existing behavior. The change has been backed out, and Jai is > improving the API docs before re-visiting the issue of readTrailer. 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30925#discussion_r3306281158
