Draft JEP, "JDK packaging guidelines"

[Andreas Ahlenstorf]

Hi Alexey,

On Tue, Feb 7, 2023, at 19:24, Alexey Semenyuk wrote:

> 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.

I fail to see how the JEP is supposed to *significantly* reduce the risk of conflicts while ignoring the registry. After all, writing into the registry is one of the main reasons to use an installer. I had a look at the JDK 19 MSIs from Amazon, Azul, Eclipse Adoptium, Oracle, and SAP [1].

Every MSI except SapMachine writes to HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft. Some ask. Some do not. There is no consistency where they write to:

Corretto: JavaSoft\JDK\19.0.2
Oracle: JavaSoft\JDK\19.0.2
Temurin: JavaSoft\JDK\19, JavaSoft\JDK\19.0.2.7
Zulu: JavaSoft\Java Development Kit\19.0.2

The Oracle MSI removed everything that was previously in HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft. All others keep what is there.

* All MSIs support adding themselves to PATH (at the front), keeping what was previously there.
* All MSIs support changing JAVA_HOME, overwriting what was previously there.
* All MSIs support associating file endings like .jar with their JDK, overwriting what was previously there.

Note: Some MSIs add an additional entry in HKEY_LOCAL_MACHINE\SOFTWARE, for example, HKEY_LOCAL_MACHINE\SOFTWARE\Eclipse Adoptium.

I can see multiple ways to proceed. The most conservative approach would probably be this one:

* Discourage HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft. Software should use JAVA_HOME for discovery as it is done on other platforms.
* Allow MSIs to overwrite JAVA_HOME, but it should be an optional feature.
* Allow MSIs to add themself to PATH (at the front), keeping what was previously there. Ideally, it should be an optional feature, too.
* Allow MSIs to overwrite file associations, but it should be an optional feature.

> 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.

I am making two separate arguments:

(1) There are significant existing conflicts in the area of the registry. Not addressing those is a disservice to the users. Overlapping installation directories are significantly easier to diagnose than the registry mess.

(2) The JEP is asking the vendors for making changes [2]. So why not ask for changes that *accidentally* help with discovery? It would offer tremendous value to the ecosystem [3].

What we currently have is not a result of everybody thinking "That's the best we could come up with." I am sure that a sizeable number of vendors would be happy to add their JDK to the already established %ProgramFiles%\Java folder (for example, %ProgramFiles%\Java\Dukecorp) if they can be sure that Oracle Legal won't come after them. An alternative approach could be to optionally register aliases in %ProgramFiles%\Java\Dukecorp to each installed JDK. 
 
> 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. 

I do not remember anything in the Linux tooling that prevents me from supporting interim releases. But it was a while ago that I looked into it.

Nonetheless, I think the proposal for the package names is too limiting. 

* It's against the established naming scheme, at least on Debian flavours. For example, Debian flavours use openjdk-17-jdk, Temurin uses temurin-17-jdk, and Azul zulu17-jdk.
* Requiring the feature number as part of the package name discourages providing useful aliases like dukecorp-latest-jdk (pointing to dukecorp-19-jdk as of now). It also prevents me from supporting interim releases if I chose to.

Requiring the dukecorp prefix seems sufficient because it can double as some sort of a namespace. Ideally, each vendor should follow the established naming scheme of the respective distribution.

> 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.

Please add the last sentence to the JEP. I have re-read the current phrasing, and it is not obvious to me that I can make up my own rules. Furthermore, the example is confusing.

Thanks,
Andreas

[1] Red Hat does not have a JDK 19 MSI on their website. As far as I know, Microsoft and IBM re-use the packaging of Eclipse Temurin, therefore I haven't checked them.
[2] None of the MSIs I looked at follows the recommended naming scheme.
[3] For example, for tools like https://github.com/HanSolo/JDKMon and its users.