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

[Alan Bateman]

On Fri, 30 Aug 2024 10:50:37 GMT, Eirik Bjørsnøs <eirbjo at openjdk.org> wrote:

>> Please review this PR with picks up on the excellent work done by @archiecobbs in #18385
>> 
>> The proposed changes aim to solve two issues with the current `java.util.zip.GZIPInputStream`:
>> 
>> *  The class parses multiple concatenated GZIP files as a single stream. This behavior is not documented in the API  specification.
>> *  Any additional bytes following a trailer which do not form a valid header are discarded and the stream behaves as if the end of stream has been reached. This behavior is not documented in the API  specification.
>> 
>> Testing:
>> 
>> * A new test `GZIPInputStreamConcat` verifies the behaviors being specified in this PR 
>> * A new test `GZIPInputStreamGzipCommand` verifies decompression of various GZIP files created using the `gzip` command.
>
> Eirik Bjørsnøs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use {@code InputStream}

I wonder if we can dig up the discussion on JDK-4691425. I can't find the CSR (or "CCC" at the time) that would have captured the reasoning for supporting this.

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

PR Comment: https://git.openjdk.org/jdk/pull/20787#issuecomment-2320873616