On Tue, 26 May 2026 16:59:10 GMT, Volker Simonis <[email protected]> wrote:
>>> @AlanBateman, but if `available()` returns 0, `readTrailer()` will return >>> `true` which will set `eos` in `read()` which will let `read()` return `-1` >>> (or "_end of the compressed input stream_") the next time it will be >>> called. And this is simply wrong if there exists more compressed members in >>> the underlying stream! >> >> I think everyone involved understands this. There is work required to find a >> solution that does not impact existing usages. We can't rule out deprecating >> the existing constructors. > >> 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30925#discussion_r3305674300
