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

[Archie Cobbs]

On Mon, 29 Jul 2024 13:06:24 GMT, Lance Andersen <lancea 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.

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

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