On Tue, 26 May 2026 15:36:47 GMT, Alan Bateman <[email protected]> wrote:
>> I'm not sure if it is the right thing to **mandate** a knowingly wrong >> implementation in the API doc which is what we effectively do in the current >> form. From my point of view, the only acceptable tag for such a sentence >> would be `@implNote` because it described implementation details which "*are >> allowed to vary across platforms, vendors, and versions*" (although this is >> unlikely nowadays where we more or less only have a single JDK >> implementation). > > @simonis It's okay to specify that it invokes the underlying stream's > available method. It is possible that you are reading this to mean that it > interprets 0 as EOF? That is not the intention. As per the discussion in > JBS, the general plan is re-visit the issue of how readTrailer behaves once > GZIPInputStream behavior is restored (already done), and once its > specification is updated to document long standing behavior. @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! If you absolutely want to back out the fix and update the API doc, then you should at least put a big, bold warning in the documentation which clearly states that `GZIPInputStream` is **not** fully RFC 1952 compatible and may **not** reliably read concatenated GZIP streams if the implementation of `available()` in the underlying input stream is not returning the correct number of remaining bytes in the stream (which it is not required to do according to the specification). This would be the correct way to "*document long standing behavior*". Instead, the current update of the API doc just mentions the use of `available()` without making the consequences clear - namely the inability to correctly read concatenated GZIP streams. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30925#discussion_r3305226749
