On Wed, 13 May 2026 10:53:23 GMT, Alan Bateman <[email protected]> wrote:
>> Jaikiran Pai has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contains 17 additional >> commits since the last revision: >> >> - merge latest from master branch >> - merge latest from master branch >> - minor adjustments >> - Lance's review >> - merge latest from master branch >> - introduce test to verify read() throws IOException when invoked on closed >> stream >> - specify existing behaviour of throwing IOException when stream is already >> closed >> - merge latest from master branch >> - specify that GZIPInputStream is not thread-safe >> - refer to section 2.2 of the RFC >> - ... and 7 more: https://git.openjdk.org/jdk/compare/f7548393...a22c1b83 > > src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 40: > >> 38: * >> 39: * <h2><a id="gzip_file_format">GZIP file format</a></h2> >> 40: * Section 2.2 of RFC-1952 specifies GZIP file format as consisting of a >> series of "members" > > The RFC specifies the GZIP file format and it might be better to link to that > first before jumping to section 2.2. Also it might be better to say that the > members appear one after another before discussing what is in each member, > e.g. > > "The GZIP file format is specified by RFC 1952. The format consists of a > series of "members" that appear one after another in the stream with with no > additional information before, between, or after. Each member consists of a > header, followed by ...". Done, I've adjusted this class level doc to follow your suggestion. Let me know if you would like additional changes. > src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 121: > >> 119: * @throws NullPointerException if {@code in} is null >> 120: * @throws IOException if an I/O error occurs when reading the >> member header >> 121: * from the underlying stream > > Are we guaranteeing that this will not attempt to read beyond the header? Hello Alan, yes, we do guarantee that when reading the header we will not read additional bytes past the header. Infact, when reading the header or the trailer of a member, we don't read or buffer additional bytes. It's only during decompressing the deflated data of a member, through the InflaterInputStream, we may read and buffer additional data that may go past a member's trailer. The only other time we read past a trailer is when we go looking for the header of the next member, after the previous member's trailer is read. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30925#discussion_r3252430207 PR Review Comment: https://git.openjdk.org/jdk/pull/30925#discussion_r3252429404
