<div dir="ltr"><div dir="ltr">On Tue, Nov 28, 2023 at 6:16 PM Alan Bateman <<a href="mailto:Alan.Bateman@oracle.com">Alan.Bateman@oracle.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This is a JDK 1.1 era mistake. It would a source incompatible change to <br>
"remove" the constants. It would require corpus searches to gauge the <br>
impact.</blockquote><div><br></div><div>Alan,</div><div><br></div><div>I've tried to assess the impact by using Github's Code Search. As far as I can tell, this searches 141M Java source files across 5K repositories.</div><div><br></div><div>I searched for various combinations of {ZipEntry, ZipFile, ZipInputStream, ZipOutputStream} and the fields of ZipConstants, weeding out things clearly derived from OpenJDK sources, forks of other repositories and repositories no longer maintained.</div><div><br></div><div>In the end I found usages of these constants in something like 10 repositories, including:</div><div><br></div><div>bazelbuild/bazel<br></div><div>h2oai/h2o-3<br></div><div>oracle/graal<br></div><div>apache/netbeans<br></div><div>facebook/buck<br></div><div>jbossas/jboss-vfs<br></div><div>jMonkeyEngine/jmonkeyengine<br></div><div><br></div><div>Most matches used just one or a few constants (checking magic numbers to guess file formats), others used more constants when parsing and/or writing ZIP files. All of them should be rather trivial to fix, the solution is for the projects to define their own constants, copying those needed from ZipConstants.</div><div><br></div><div>Based on the results of my search, my guess is that the disruption should be fairly limited. Zip file format parsing is just not something Java programmers do very often.</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"> I think the question is whether it's worth the disruption, is <br>
your motivation to cleanup this area or something stronger?<br></blockquote><div><br></div><div>The reason I started looking at this was that I was looking into refactoring ZipUtils. There is a good amount of code duplication in how fields are read. These efforts were complicated by the constants being "effectively public", since I can't rename them or remove them.</div><div><br></div><div>To summarize my motivations:</div><div><br></div><div>- These constants distract and confuse current and future users of the APIs, stealing cycles better spent elsewhere</div><div>- Likewise, current and future maintainers of OpenJDK will also find them confusing</div><div>- They limit or prevent certain code cleanups and improvements</div><div>- They are aesthetically unpleasing. This concern is perhaps not typically appreciated in an engineering culture. But in this case, these mysteriously named fields in a widely used public API just feels wrong. Knowing they got there by mistake does not make this better. It's just Matter Out Of Place". Every product or technology has a certain "weirdness budget". These constants are eating into Java's. Fixing this will free up some weirdness dollars, I'm sure we can find better use for them elsewhere :-) </div><div><br></div><div>I think I'm done hammering this nail for now. I would love to deprecate the constants and see them go some releases down the road. But that would need a broader consensus which I'm not sure we have. </div><div><br></div><div>Thanks,</div><div>Eirik.</div></div></div>