Draft JEP, "JDK packaging guidelines"

[Alexey Semenyuk]

Hi Andreas,

Thank you for your feedback.

This JEP provides guidelines for JDK packaging to help JDK vendors avoid 
conflicts. Following these guidelines will reduce the risk of publishing 
JDK packages that will conflict with each other.

The scope of the JEP is limited on purpose. Covering all spectrum of 
issues with JDK deployment and discovery, e.g. imposing limitations on 
installation locations of JDKs on Windows will likely make the JEP 
useless. It would be hard to find a consensus on the matter.

The "Promote a stable installation directory within a feature release 
family to make it easier for applications to find the current update 
release" goal is not addressing all JDK discovery issues. But it helps 
applications depending on JDK from a specific vendor find the latest 
version of the feature release family.

I agree the JEP will benefit from covering user-specific Windows 
installations that usually go into C:\Users\<username>\AppData\Roaming.

Users can have multiple interim releases side by side if they install 
JDK from an archive. System-wide installations don't support 
side-by-side installations of interim releases on Linux. It doesn't 
apply to macOS and Windows. But the JEP promotes adopting this approach 
on these platforms addressing JDK discovery issues on these platforms to 
a limited extent.

It is a good question whether we should leave JRE behind or should the 
JEP cover deprecated features.

For alternative framework group priority, the JEP proposes "The JDK 
version number should be encoded in the priority value so that higher 
JDK versions have a higher priority". 1900100 for JDK 19.0.1 is an 
example. Vendors can define their own "version to priority" mapping scheme.

- Alexey

On 2/3/2023 11:21 AM, Andreas Ahlenstorf wrote:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230207/50f62d72/attachment-0001.htm>