Draft JEP, "JDK packaging guidelines"

[Andreas Ahlenstorf]

Hi Alexey,

On Thu, Feb 2, 2023, at 21:57, Alexey Semenyuk wrote:

> The JEP provides guidelines for JDK packaging on Linux, Windows, and macOS for better interoperability among different JDK vendors. It covers platform specific packaging and doesn't cover compressed/archive JDK bundles, such as zip or tar.

Thanks a lot for putting this guidance together. I'm happy to see this.

I have a couple of remarks.

The distinction between setup routines and package managers on one side and everything else (including archives) on the other side seems artificial. As a user, I do not care how the JDK came onto my computer. What matters is where it ends up and that it integrates with the system. For example, I can craft a JDK archive that, when extracted to /Library/Java/JavaVirtualMachines, works as if it was installed by a PKG. Therefore, I argue to shift the focus from "That's how setup routines should operate" to "Those are the places where the JDK should be put and how the folders should be named".

One of the stated goals of the JEP is to "Promote a stable installation directory within a feature release family to make it easier for applications to find the current update release". The proposed solution for Windows fulfils that objective only partially. Let's take %ProgramFiles%/Dukecorp/jdk-19. How is an application supposed to figure out that it has to look in %ProgramFiles%/Dukecorp for JDKs? That's part of a bigger issue: Contrary to Linux and macOS, there is no easy way to discover all installed JDKs. On Linux, I can look into /usr/lib/jvm. On macOS, I can enumerate /Library/Java/JavaVirtualMachines. On Windows, there is no easy way to do the same. The only option is to scan %ProgramFiles% in its entirety and to look for known files/programs like javac. Alternatives I can imagine:

(1) Define a single root directory for all JDKs (like on Linux and macOS). Drawback: It might go against the standards established by Microsoft.
(2) Tell vendors to register each JDK or installation directory in the registry. Disadvantage: It does not work with archives.

There is another aspect to the discovery problem on Windows. Historically, a lot of tooling relied on well-known registry keys like HKLM\Software\JavaSoft\Java Runtime Environment\CurrentVersion to discover the JDK to use. Therefore, some vendors still write to these locations to make their version the preferred JDK. Standardizing this mechanism or introducing a new one would benefit the whole ecosystem. I know that it is stated as a non-goal. But at the same time, it is a problem.

Another Windows concern: Installation into the user profile (C:\Users\<username>\AppData\Roaming) is widespread. Defining the same rules there might make sense.

Including the feature number alone in the installation directory implies that users cannot have multiple interim releases side by side. This is a theoretical concern (at least for now), but it should be made explicit, nonetheless.

"jdk" is supposed to be included as a prefix or postfix in the name of the installation directory. How should vendors change the path when they are shipping a JRE? I know that the JRE has been deprecated for a long time, but OpenJDK 8 still receives patches, and the JEP even mentions JDK 7. Therefore, considering the JRE only seems fair.

Alternative framework groups: At least Debian flavours additionally distinguish between "headless" (CLI) and "headful" (display a GUI) programs. However, it may not matter because I have never observed any problems caused by misclassification.

Alternative framework group priority: The JEP proposes 1900100 for JDK 19.0.1. How should $FEATURE.$INTERIM.$UPDATE.$PATCH be mapped to the priority value? Two digits per component? One? 1900100 has seven digits. Therefore, I'm unsure. What about the fifth element of the version number mentioned by JEP 322?

Thanks,
Andreas