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