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

[Archie Cobbs]

On Wed, 28 Aug 2024 17:50:36 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert all functional changes, leaving only tests & Javadoc.
>
> src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 43:
> 
>> 41:  * frame that marks the end of the compressed data. Therefore it's possible for the underlying
>> 42:  * input to contain additional data beyond the end of the compressed GZIP data. In particular,
>> 43:  * some GZIP compression tools function by partitioning the input, compressing each parttion
> 
> I think we need to simplify the above  keeping the focus on that GZIPInputStream supports the reading of concatenated  Gzip streams.  After reading  a streams trailer(though some docs refer to it as a footer, but I think we go with trailer),  if an additional gzip header is found, the stream will be decompressed... etc.. 
> 
> If there is additional data/byes after the trailer that does not represent another gzip, header, it will indicate you have reached the end of the input stream

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.

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

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