On Mon, 29 Jul 2024 13:52:57 GMT, Archie Cobbs <aco...@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
