Revisiting JDK-4512189: ZipConstants leaking into public APIs

[Eirik Bjørsnøs]

On Tue, Nov 28, 2023 at 6:16 PM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> This is a JDK 1.1 era mistake. It would a source incompatible change to
> "remove" the constants. It would require corpus searches to gauge the
> impact.


Alan,

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.

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.

In the end I found usages of these constants in something like 10
repositories, including:

bazelbuild/bazel
h2oai/h2o-3
oracle/graal
apache/netbeans
facebook/buck
jbossas/jboss-vfs
jMonkeyEngine/jmonkeyengine

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.

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.


> I think the question is whether it's worth the disruption, is
> your motivation to cleanup this area or something stronger?
>

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.

To summarize my motivations:

- These constants distract and confuse current and future users of the
APIs, stealing cycles better spent elsewhere
- Likewise, current and future maintainers of OpenJDK will also find them
confusing
- They limit or prevent certain code cleanups and improvements
- 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
:-)

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.

Thanks,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20231201/2a0e0ad5/attachment-0001.htm>