RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v9]

[Eirik Bjørsnøs]

On Wed, 28 Aug 2024 19:56:04 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Sounds good. How would you like to do that?
>> 
>> E.g. we could just remove the words "In particular, some GZIP compression tools function by partitioning the input, compressing each partition separately, and then concatenating the resulting compressed data streams. To support this kind of input".  We could also remove "In the latter case, the number of additional bytes that were read is unspecified." Or something else (what would you suggest?)
>> 
>> Thanks.
>
>> Sounds good. How would you like to do that?
>> 
>> E.g. we could just remove the words "In particular, some GZIP compression tools function by partitioning the input, compressing each partition separately, and then concatenating the resulting compressed data streams. To support this kind of input". We could also remove "In the latter case, the number of additional bytes that were read is unspecified." Or something else (what would you suggest?)
>> 
>> Thanks.
> 
> Yes, no reason to talk about gzip tools.  The focus should be that this method can read concatenated gzip streams when there is a gzip header immediately after the gzip trailer, otherwise additional bytes are treated as End of stream

I'm reluctant to make this PR even longer lived. But perhaps this could be made even shorter by dropping the 'self-delimiting' term and its definition?

Could something like this work?

_In the GZIP file format, compressed data payloads are preceded by a header and followed by a trailer. If a new header immediately follows a trailer, this class continues to decode compressed data as a single, concatenated stream; otherwise, any additional bytes are ignored as if the end of stream is reached._

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18385#discussion_r1736027146