Provide Oracle JDK compatible registry keys (Windows) about installer HOT 22 CLOSED

I think I'm sensing that strategically we should set our own key (don't break other Java's on the system because that's not nice) and work with the common installer libraries/frameworks/companies to pick up our registry key alongside, say, IBM's, Oralce's etc.

Would that satisfy folks? If so we can make a list of the common libraries/frameworks/companies and @gdams can reach out to them.

from installer.

I don't think that's a good move.

For one, the way the license change in Oracle Java 11 and the pitching of OpenJDK as the proper alternative was communicated, a huge amount of people out there come with the expectation of OpenJDK as a drop-in replacement. So if they don't get that, they are dissatisfied and probably move on.

At the same time, there is a good deal of software out there relying on the current registry entries, and experience shows that adoption of new entries by installers etc will take a while, and then it'll take even longer until all their clients have picked up those new versions for their software. By then, most folks will probably have settled in with a different distribution that fits their needs.

I have recently brought one of my own projects up to speed for Java 11, and looking into what OpenJDK installation to suggest to our users was part of it (we might move to a bundled JRE in the future though, making the point moot). I really like AdoptOpenJDK and how it presents a clear choice of JDK versions in an easily accessible fashion. But the fact that there isn't a Java 11 installer for Windows was a blocker for me. And an "incompatible" registry key would be as well. While it would be easy to get my own project to use your key, I'd still face a significantly high risk that it won't work with other software of my users, and their dissatisfaction would fall back on me. So right now, I'll go with Ojdkbuild, because it ticks all the boxes and looks the most vendor-neutral.

from installer.

To be a bit more constructive: As suggested before, I'd present the option to create the JavaSoft key in the installer, as most of the other distributions seem to do already. I also like the idea of not overwriting an existing key. So I would suggest something like

1. always write to your own key
2. present the option to create the JavaSoft key in the installer
3. select the option by default if the key does not exist yet, and deselect it if there already is one

This way, the AdoptOpenJDK installer plays nice with other distributions, yet fulfills all user expectations. And it also "softly" establishes your own key. I wouldn't worry too much about other installers overwriting the JavaSoft key, since a) you'd still have your own key (1.) and b) the user would still get their expected experience of their software picking up a JDK (just not yours anymore).

from installer.

As the last comment on the link included from ADAM at Launch4j

Zulu does write to the registry, but it has 2 different behaviours.
If Oracle Java is installed then Zulu writes to it's own locations. If Oracle Java is not installed, then Zulu writes to it's own locations AND the traditional Oracle ones.
In this second case launch4j picks it up without any further changes. However in the former case (which we believe will be very common) then Zulu is not selected.
By default Zulu installer doesn't add itself to the PATH.

Did we want to do the same things as Zulu ( dont override Oracle reg key ) ?
Or override it to allow Adopt to be used even if Oracle is already installed ?

Also see https://docs.oracle.com/javase/9/install/installation-jdk-and-jre-microsoft-windows-platforms.htm#JSJIG-GUID-47C269A3-5220-412F-9E31-4B8C37A82BFB
(two different reg key to create with the "new version-string format introduced in JDK 9"

from installer.

As the last comment on the link included from ADAM at Launch4j

Zulu does write to the registry, but it has 2 different behaviours.
If Oracle Java is installed then Zulu writes to it's own locations. If Oracle Java is not installed, then Zulu writes to it's own locations AND the traditional Oracle ones.
In this second case launch4j picks it up without any further changes. However in the former case (which we believe will be very common) then Zulu is not selected.
By default Zulu installer doesn't add itself to the PATH.

Did we want to do the same things as Zulu ( dont override Oracle reg key ) ?
Or override it to allow Adopt to be used even if Oracle is already installed ?

Also see https://docs.oracle.com/javase/9/install/installation-jdk-and-jre-microsoft-windows-platforms.htm#JSJIG-GUID-47C269A3-5220-412F-9E31-4B8C37A82BFB
(two different reg key to create with the "new version-string format introduced in JDK 9"

We should not override other vendors.

from installer.

yes JavaSoft is a trademark .. but If we write to this key when oracle is not already installed I presum that Oracle will override it.
So must we write to it even if Oracle is not installed ?

from installer.

If we dont override each other key, we can't make this information available for third party.
So each vendor should create his key and Launch4J must check around many keys ( one for each compatible vendor ) ?

from installer.

• Ojdkbuild propose to create this reg key as an option enabled by default
• Zulu dont ask for create and remove reg key "HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development Kit" even if this is not their values
• Oracle remove key "Java Runtime Environment" created by ojdkbuild if "JRE" is not checked during install
• Amazon Corretto uninstall and supress CurentVersion living it missing

I think we definitly can't write/remove this key already shared by other vendor because uninstall will break other vendor and install can overrite other key

CurrentVersion mean nothing because we can having many current version at same time ( one for JDK 8 and one for JDK 11 )

It is probably less risky to create our key and software who want find/support AdoptOpenJDK can look a this keys
[HKEY_LOCAL_MACHINE\SOFTWARE\AdoptOpenJDK\Java Development Kit]
with
JavaHome
RuntimeLib
and not CurrentVersion but maybe : LatestInstalledVersion
Or CurrentVersion8 / CurrentVersion11 .. and so on

from installer.

If we dont override each other key, we can't make this information available for third party.
So each vendor should create his key and Launch4J must check around many keys ( one for each compatible vendor ) ?

Of course best solution would be if each software would look for keys for each JDK, but that will never happen. Even if Launch4J starts looking for other JDK keys there will be many projects left that rely on Launch4J are not updated anymore.
So IMHO there is a need for some work around. Maybe just a "set default JavaSoft registry keys" option in the installer.

from installer.

and not CurrentVersion but maybe : LatestInstalledVersion

Sorry for the +1, but we too rely on CurrentVersion, which points us to the relevant key. Currently, to circumvent this, we do a try/catch on a shell execute of java.exe which grabs it from the path.

Since Oracle's Java 11 is only available in SDK, we've (recently) already had to shim support for fallback keys so adding another fallback is not a concern nor is the location/name (albeit needed). What's important (from my/our perspective) is the knowledge of what the latest/current actually is so we can add support for finding it.

from installer.

Also, cross-linking to one (of many) tools that try to make similar assumptions. :) https://nsis.sourceforge.io/A_slightly_better_Java_Launcher. If AdoptOpenJDK is going to be a replacement for the shared Java on a system, these types of communal techniques can/should be updated once a decision is made.

from installer.

• Ojdkbuild propose to create this reg key as an option enabled by default
• Zulu dont ask for create and remove reg key "HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development Kit" even if this is not their values
• Oracle remove key "Java Runtime Environment" created by ojdkbuild if "JRE" is not checked during install
• Amazon Corretto uninstall and supress CurentVersion living it missing

I think we definitly can't write/remove this key already shared by other vendor because uninstall will break other vendor and install can overrite other key

CurrentVersion mean nothing because we can having many current version at same time ( one for JDK 8 and one for JDK 11 )

It is probably less risky to create our key and software who want find/support AdoptOpenJDK can look a this keys
[HKEY_LOCAL_MACHINE\SOFTWARE\AdoptOpenJDK\Java Development Kit]
with
JavaHome
RuntimeLib
and not CurrentVersion but maybe : LatestInstalledVersion
Or CurrentVersion8 / CurrentVersion11 .. and so on

Hi @douph1 - So to be clear there are other vendors who do set the JavaSoft key? Or is it only Oracle that does?

from installer.

All the above Ojdkbuild, Zulu Amazon ... and some dont override Oracle one like stated in #77 https://github.com/poidasmith/winrun4j/blob/master/WinRun4J/src/java/VM.cpp
#define IBM_JRE_REG_PATH TEXT("Software\IBM\Java2 Runtime Environment")

from installer.

@thenktor

Of course best solution would be if each software would look for keys for each JDK,

Fine :)

but that will never happen.

Why ?
WinRun4J already do this for "IBM" reg key

Even if Launch4J starts looking for other JDK keys there will be many projects left that rely on Launch4J are not updated anymore.

Project not updated arent dead project ?
They will continue to work with old Oracle

from installer.

@tresf

; Find JRE (javaw.exe)
; 1 - in .\jre directory (JRE Installed with application)
; 2 - in JAVA_HOME environment variable
; 3 - in the registry
; 4 - assume javaw.exe in current dir or PATH

JAVA_HOME ( second choice ) is provided with AdoptOpenJDK so https://nsis.sourceforge.io/Java_Launcher can work without relaying on Oracle "JavaSoft" tm reg key

from installer.

JAVA_HOME ( second choice ) is provided with AdoptOpenJDK so https://nsis.sourceforge.io/Java_Launcher can work without relaying on Oracle "JavaSoft" tm reg key

%JAVA_HOME% is not toggled on by default, so I would argue that it cannot be consider "reliable" from a support perspective. %PATH% is current reliable assuming new installers do a good job of removing old ones from the %PATH% on "upgrade" (upgrade meaning a new version is installed side-by-side the old).

from installer.

Why ?
WinRun4J already do this for "IBM" reg key

Tagging @poidasmith.

CurrentVersion mean nothing because we can having many current version at same time ( one for JDK 8 and one for JDK 11 )

I'm bringing this statement back up again as I haven't seen any mention of it. CurrentVersion from a Desktop support perspective usually means "the last one you installed". Although developers run JDK8/JDK11 side-by-side, users tend to just have one runtime and hope it works. WinRun4J seems to have some intelligence around the concept of MIN/MAX which can help if there's a known major version to target. From my corner of the world, we had historically targeted whatever java.com linked to while trying to maintain backwards compatibility for some time.

But I still have concerns with this mentality. If you're adding java.exe and friends to %PATH%, then you're essentially controlling current version anyway unless you're not clearing old values from the path, which will cause some upgrade problems (or prepend versus append influencing the search path).

Slightly off-topic does WinRun4J use the CurrentVersion value? The code defines it, but at a glance doesn't use it.

If AdoptOpenJDK is to be a drop-in replacement for Oracle Java, developers utilizing it need to know how to find it and I think that's the OP's point.

from installer.

Sounds like a reasonable compromise to me

from installer.

@douph1 can you help us with this one?

from installer.

I have begin,
As spotted in the Oracle doc:
https://docs.oracle.com/javase/9/install/installation-jdk-and-jre-microsoft-windows-platforms.htm#JSJIG-GUID-C11500A9-252C-46FE-BB17-FC5A9528EAEB

This key contains the string CurrentVersion, with a value that is the highest installed version on the system.

I have done this ( not to set CurrentVersion blindly ... => Replace value only if the installer version is newer than the "CurrentVersion" already installed )

Oracle write in different key
HKEY_LOCAL_MACHINE\Software\JavaSoft\ JRE
or/and
HKEY_LOCAL_MACHINE\Software\JavaSoft\ Java Runtime Environment
and/or
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\ JDK
and/or
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\ Java Development Kit

If there are two versions of JDK or JRE installed on a system, one with the new version-string format introduced in JDK 9, and the other with the older version format, then there will be two different CurrentVersion registry key values. For example, if JDK 1.8.0 and JDK 9 are installed, then the following registry keys are created:

I must try to manage .. if possible:

• choosing key based on older or newer version-string format introduced in JDK 9
• choosing key based on JRE or JDK

And just one note to everyone :

MSI Installer works as is: If a registry key is handled by many installers, it will be removed only when the last installer is uninstalled.

So if we replace the JavaSoft (created by Oracle) key value with an Adopt value it will not delete the JavaSoft key when Adopt is uninstalled and will let the value CurrentVersion (Adopt Value which is missing) as is

I think it is a problem and another reason too not write to a key managed by someone else already ... and simply not to share a key with multiple installers

from installer.

todo:

• need to handle Wow6432Node // done by wix natively
• RuntimeLib // done

from installer.

By overriding JavaSoft key we will be hit by this bug: corretto/corretto-8#36
because Oracle set a (preprend) Path "C:\Program Files (x86)\Common Files\Oracle\Java\javapath" with a "fake" java.exe which search for Reg key to locate the "CurrentVersion" java.exe

https://stackoverflow.com/questions/49540325/which-jre-does-c-programdata-oracle-java-javapath-java-exe-use

from installer.