On Mon, 4 May 2026 20:22:52 GMT, Lance Andersen <[email protected]> wrote:
>> My initial thought was to include some of these details in the class level
>> doc. However, when trying to word that text, I almost always either had to
>> refer to the `read()` method and/or the buffer passed to the read method.
>> Unless of course I split some of that text in the class level doc and some
>> in the read() method doc. I decided that it would be better to explain these
>> details here as a method level doc. That way we can be a bit more precise on
>> how we word it.
>>
>> If there's a better way to word it and place it as class level doc, then let
>> me know and I'll give it a try.
>
>>
>> If there's a better way to word it and place it as class level doc, then let
>> me know and I'll give it a try.
>
> Perhaps something like the following might work:
>
> ++++++++++++++++++++
> When processing a GZIP stream, this class may read ahead in the underlying
> stream while completing a member or determining whether another member
> follows. Consequently, an unspecified number of bytes beyond a member’s
> trailer may be consumed.
>
> If the bytes read ahead do not constitute a valid header for a subsequent
> member, the stream is considered to have reached end-of-stream, and further
> reads return {@code -1}.
>
> For concatenated GZIP streams, each invocation of {@link #read(byte[], int,
> int)} yields decompressed data from at most one member; data from multiple
> members is not combined in a single read operation.
>
> ++++++++++++++++++++
Hello Lance, I've updated the PR to use your suggested text at the class level.
I have done minor adjustments to the ordering and the text. If it looks OK to
you, then I'll update the CSR text to match the current state in this PR.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/30925#discussion_r3188351871
