On Tue, 5 May 2026 12:56:38 GMT, Lance Andersen <[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 14 additional >> commits since the last revision: >> >> - 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 >> - remove additional sentence from constructor documentation >> - Lance's review - clarify implicit vs explicit close() >> - merge latest from master branch >> - ... and 4 more: https://git.openjdk.org/jdk/compare/0bc58956...f3b4d725 > > src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 53: > >> 51: * <p> >> 52: * When {@linkplain #read(byte[], int, int) reading}, this class may >> read ahead in the underlying >> 53: * stream while completing a member or determining whether another >> member follows. Consequently, > >> When {@linkplain #read(byte[], int, int) reading}, this class may read ahead >> in the underlying > > I think the above needs a bit of word smithing as "When reading, this class > may read...." as it feels "reading" and then "read" seem a bit redundant. If > you prefer to not use "When processing the GZIP Stream", which is fine, we > just need a different opening to the sentence. Done. I wanted to point to the read method when explaining when those additional bytes might be read, so I had tweaked your original text a bit. I have now updated the PR to use your original suggestion of "When processing..." and used a `{@linkplain` to point to the read method. Let me know if any additional changes might be necessary. > src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 56: > >> 54: * an unspecified number of bytes beyond a member’s trailer may be >> consumed. If the bytes read >> 55: * ahead do not constitute a valid header for a subsequent member, the >> stream is considered to >> 56: * have reached end-of-stream, and {@code read()} returns {@code -1}. > >> {@code read()} returns > > I think this would be better something like "the read method" given > readTrailer(), which is called via read(byte[], int, int) Fixed in the updated version of the PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30925#discussion_r3188729927 PR Review Comment: https://git.openjdk.org/jdk/pull/30925#discussion_r3188730941
