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