On Tue, Nov 28, 2023 at 10:38 AM Eirik Bjørsnøs <eir...@gmail.com> wrote:
> > > On Tue, Nov 28, 2023 at 5:28 PM David Lloyd <david.ll...@redhat.com> > wrote: > >> I agree, I always thought that this was a bizarre thing to expose in a >> public API so it being accidental does explain things. But maybe the >> appropriate fix is even simpler now in these modern times: one could remove >> the `implements` and add a `static import` of `ZipConstants.*`, which at >> approximately one or two lines is a much more minimal (and >> conflict-resistant, for those who care about backporting subsequent fixes >> of this class) change IMO. >> > > Thanks David! > > Not entirely sure I understand what you suggest this as an alternative to. > Removing "implements" and replacing that with static imports is surely > where I would eventually see this going. > I was "responding" to the (22-year-old?) suggested fix on the JIRA bug, perhaps unnecessarily; my apologies. > But before we get there, I think we need to discuss the compatibility > impact of such a change, and how to go about it with regards to the > deprecation process etc. > Makes sense to me. FWIW (maybe not much) I think your analysis of the source vs binary compatibility impact is correct. Peeking at `java.util.zip.ZipConstants` with `javap` reveals that the fields do indeed have the expected `ConstantValue` attribute which seems to support your conclusion per JLS § 13.1 [1]. [1] https://docs.oracle.com/javase/specs/jls/se21/html/jls-13.html#jls-13.1 -- - DML • he/him
