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

[Lance Andersen]

On Mon, 29 Jul 2024 13:52:57 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> > So where does that leave us:
> > Keep the code as is and document the current behavior
> > Continue to add additional test coverage for the current API
> > We probably do not need a new constructor given it probably adds no new additional value the existing API
> 
> Just so I understand... are you saying that you are OK with this class being fundamentally unreliable _and_ providing no way to avoid that unreliability? (Just to restate a previous example of this: if an underlying `IOException` occurs at just the wrong time, an application that wrote `GZIP-STREAM-1`, `GZIP-STREAM-2`, `GZIP-STREAM-3` could read back `GZIP-STREAM-1`, `GZIP-STREAM-2` and never know that anything was wrong.)
> 
> If that's _not_ what you're saying, then I don't the understand "We probably do not need a new constructor" part.

What I am suggesting is before we move forward, we really need:

- More test coverage
- An understanding of what other gzip API and tools(commons-compress, gzip, python, etc...) might do (or do not do) with the problem you are trying to address

The Java ZIP APIs date back to the early days of Java (1.1/1.2) and changes(fixes) often can cause unexpected regressions so we have to thread lightly.

I am not opposed to making the API more robust, we really need more datapoint to better understand the risks/benefits in order to make an informed decision.

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

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