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

Lance Andersen lancea at openjdk.org
Wed Jul 31 15:54:35 UTC 2024


On Tue, 30 Jul 2024 19:00:13 GMT, Archie Cobbs <acobbs 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.)

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.

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

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


More information about the core-libs-dev mailing list