<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 28, 2023 at 10:01 AM Eirik Bjørsnøs <<a href="mailto:eirbjo@gmail.com">eirbjo@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<br><div><br></div><div>JDK-4512189 [1] raised the issue that ZipFile, ZipEntry, ZipInputStream and ZipOutputStream all implement the non-public ZipConstants interface. While the interface itself is non-public, the constants defined unfortunately leak into the public API as constants of the mentioned classes. This means they show up in Javadoc, and maybe worse in code completions.</div><div><br></div><div>JDK-4512189 was closed in 2001 because of concerns of binary compatibility:<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Unfortunately, whether or not a class implements an interface is part of the classes public API and having those classes *not* implement ZipConstants will break binary compatibility. Therefore, unfortunately, this bug is being closed as will not fix. </blockquote><div><br></div><div>However, will this really break binary compatibility? Any reference to ZipFile.CENSIG or any other constant (which are all of type long and int) will be compiled into byte code in the referencing class, with or without a copy of the constant in the constant pool of the referencing class. Thus, any compiled reference should continue to work.</div><div><br></div><div>There is of course a source compatibility issue, but these constants should generally not be of interest to anyone outside the implementation, and if anyone is accidentally using them, it's most probably a bug. In any case, they would get warned when trying to recompile their sources. The easy solution then will be to define their own constants or fix the bug.</div><div><br></div><div>In light of this, I would like to revisit this issue, 22 years later:</div><div><br></div><div>- Is my assessment that this change is actually not binary incompatible sound, or did I miss something?</div><div>- Would it in any case make sense to mark ZipConstants as @Deprecated, maybe for removal to alert people we want to remove the constants?</div><div>- Could we aim to make the mentioned classes *not* implement ZipConstants, following the regular deprecation process, CSR and release note etc?</div></div></blockquote><div><br></div><div><span style="font-family:arial,helvetica,sans-serif">I agree, I always thought that this was a bizarre thing to expose in a public API<span class="gmail_default" style="font-family:arial,helvetica,sans-serif"> so it being accidental does explain things</span>. But maybe the appropriate fix is even simpler now<span class="gmail_default" style="font-family:arial,helvetica,sans-serif"> in these modern times</span>: <span class="gmail_default" style="font-family:arial,helvetica,sans-serif">one could </span>remove the `implements` and <span class="gmail_default" style="font-family:arial,helvetica,sans-serif">add</span> a `static import` of `ZipConstants.*`, which <span class="gmail_default" style="font-family:arial,helvetica,sans-serif">at approximately one or two lines is a much more</span> minimal <span class="gmail_default" style="font-family:arial,helvetica,sans-serif">(and conflict-resistant, for those who care about backporting subsequent fixes of this class) change IMO.</span></span></div></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">- DML • he/him<br></div></div></div>