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

[Archie Cobbs]

On Wed, 31 Jul 2024 15:51:48 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Another (more conservative) possibility is to preserve both 1 ("Trailing garbage is ignored") and 3 ("Concatenated streams are automatically decoded") in the default configuration.
>> 
>> Then basically all we would be changing is no longer suppressing `IOException`'s.
>> 
>> And then - as a separate remaining question - if we wanted to also provide more control there could be new constructor(s) to control concatenation and/or tolerance for trailing garbage.
>> 
>> (In all cases, I think using `mark()`/`reset()` (when available) to make trailing garbage detection precise is a good idea.)
>
>> Another (more conservative) possibility is to preserve both 1 ("Trailing garbage is ignored") and 3 ("Concatenated streams are automatically decoded") in the default configuration.
>> 
>> Then basically all we would be changing is no longer suppressing `IOException`'s.
>> 
>> And then - as a separate remaining question - if we wanted to also provide more control there could be new constructor(s) to control concatenation and/or tolerance for trailing garbage.
>> 
>> (In all cases, I think using `mark()`/`reset()` (when available) to make trailing garbage detection precise is a good idea.)
> 
> We don't want to change this long standing behavior as it has the potential of breaking existing applications and it is consistent with gzip and also winzip.
> 
> So through this PR, we should clarify the javadoc as to what  current GZIPInputStream implementation  does  and add additional tests to  expand the coverage
> 
> A separate discussion can take place to discuss the merits of whether there is perceived value in throwing an IOException when trailing garbage is encountered as well as any benefit of not supporting concatenated gzip files.  It will also allow time for further review of other tools/apis that support gzip to see what they may or may not do.

@LanceAndersen & @jaikiran,

When you get a chance please review the [CSR](https://bugs.openjdk.org/browse/JDK-8330195) and let me know if you think the new wording is appropriate.

Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/18385#issuecomment-2302856157