On Fri, 30 Aug 2024 10:50:37 GMT, Eirik Bjørsnøs <eir...@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
