installer
installer copied to clipboard
adoptium
MSI Installer adds JDK to beginning of System's PATH variable
Upon installation of the JDK with the MSI installer, the installer configures the JDK directory right at the beginning of the System's PATH environment variable. According to some Windows experts, the JDK path should be appended to the end of System's PATH, or as a User's PATH variable.
Secondary bug: when JAVA_HOME feature is selected in the MSI installer, it will configure this variable in the System's variables table, but it will not reference it in the PATH environment variable. Meaning: the full path of the JDK is in the PATH and in the JAVA_HOME.
As for clarity, this is how Path is evaluated on Windows terminals:
Path = %Path% (System) ; %Path% (User)
Here are the changes I believe are adequate for the MSI installer, but most importantly, to initiate the discussion:
- Add a way to allow the user to choose whether to configure the JDK in the User variables or System variables. The default selection should be
User. - If the user selects System, it should be appended (end). If user selects User variable, it should be prepended (start).
- If the user selects JAVA_HOME to be configured, the PATH variable should reference it -
%JAVA_HOME%\bin.
For comparison, the Windows Installers from Oracle no longer configures the JDK ./bin path in PATH. They also don't set JAVA_HOME either.
Oracle's approach is simple: it has shim binaries for java.exe, javac.exe, javaw.exe, and jshell.exe on a separate folder. That folder is then prepended into the System variable PATH.
Once a user installs a newer JDK, the installer updates the shim binaries. If the user uninstalls a newer Oracle JDK, while still having an older Oracle JDK available, the shim rollback automatically. I have not looked into the details, but most likely this shim map is done in the Windows registry.
This prevents any conflict between JDK tools and Windows tools, such as klist.exe, which exists both on Windows and on the JDK. For most scenarios, and especially for students, this approach is very adequate, despite prepending a folder to the System PATH, because such folder contains an extremely limited set of executables - all very much Java-specific.
Issue with klist.exe
Currently with Temurin (and MS Build of OpenJDK), once the MSI installer is complete, klist no longer points to the Windows program, but to the JDK one.
Hi,
According to some Windows experts, the JDK path should be appended to the end of System's PATH,
Source ?
or as a User's PATH variable.
By default the jdk is installed per machine(admin right required) and not per user. If msi install is forced per user, it make sense
Secondary bug: when JAVA_HOME feature is selected in the MSI installer, it will configure this variable in the System's variables table, but it will not reference it in the PATH environment variable. Meaning: the full path of the JDK is in the PATH and in the JAVA_HOME.
Yes actually JAVA_HOME is not reused in PATH, this is two different things. (I don't know if expended variable works) And into Wix Setup it is probably not easy to change a "feature" if another "feature" is selected. I probably don't want that changing my JAVA_HOME var will change my PATH. Is it hot or cold change only ?
Add a way to allow the user to choose whether to configure the JDK in the User variables or System variables. The default selection should be User.
For default install this is not a good choice as it is installed per machine, so configure it in "user variable" from admin account will not reflect it for users account.
For user installed msi it is probably already the case : Note that per-user-install is a edge case note properly documented in Website https://github.com/adoptium/installer/tree/master/wix#per-user-install
If the user selects System, it should be appended (end). If user selects User variable, it should be prepended (start).
It is preprended since the beginning I think so the new installed one take precedence on the older one. For many end-user it is the way to go and the expected way. If you installed a new java and put it at then end it will not be used until another action like, uninstall all previous JDK or specifing the full path. I think many user expect it will be taken into account on next reboot without more work.
If the user selects JAVA_HOME to be configured, the PATH variable should reference it - %JAVA_HOME%\bin.
What the pro and cons for this ?
I fully understand the long known issue about klist.exe.
shim binaries is a good alternative who permit to get new jdk for services without restart and already proposed in https://github.com/adoptium/installer/issues/133 You can add you contribution here.
The main problem here is probably that the default PATH update (prepend) is always done
FeatureMain | Core AdoptOpenJDK installation (DEFAULT) FeatureEnvironment | Update the PATH environment variable (DEFAULT)
If PATH is not needed maybe zip is a better option to handle JAVA_HOME and PATH by yourself. I think we must continue to set the PATH in default setup and do it like before ( prepend ). Maybe it is possible to add a feature to change the default behaviour from "FeatureEnvironment" so JDK will be appended. I don't know. Help wanted.
If possible it will probably be simpler than shim binaries to fix klist.
According to some Windows experts, the JDK path should be appended to the end of System's PATH,
Source ?
The Windows team at Microsoft, they let us know internally :-).
or as a User's PATH variable.
By default the jdk is installed per machine(admin right required) and not per user. If MSI install is forced per user, it make sense
Secondary bug: when JAVA_HOME feature is selected in the MSI installer, it will configure this variable in the System's variables table, but it will not reference it in the PATH environment variable. Meaning: the full path of the JDK is in the PATH and in the JAVA_HOME.
Yes actually JAVA_HOME is not reused in PATH, this is two different things. (I don't know if expended variable works) And into Wix Setup it is probably not easy to change a "feature" if another "feature" is selected. I probably don't want that changing my JAVA_HOME var will change my PATH. Is it hot or cold change only ?
Add a way to allow the user to choose whether to configure the JDK in the User variables or System variables. The default selection should be User.
For default install this is not a good choice as it is installed per machine, so configure it in "user variable" from admin account will not reflect it for users account.
For user installed MSI it is probably already the case : Note that per-user-install is a edge case note properly documented in Website https://github.com/adoptium/installer/tree/master/wix#per-user-install
If the user selects System, it should be appended (end). If user selects User variable, it should be prepended (start).
It is preprended since the beginning I think so the new installed one take precedence on the older one. For many end-user it is the way to go and the expected way. If you installed a new java and put it at then end it will not be used until another action like, uninstall all previous JDK or specifying the full path. I think many user expect it will be taken into account on next reboot without more work.
If the user selects JAVA_HOME to be configured, the PATH variable should reference it - %JAVA_HOME%\bin.
What the pro and cons for this?
Pros are the java, javac and other tools can be immediately used from the Command Line.
I fully understand the long known issue about klist.exe.
shim binaries is a good alternative who permit to get new jdk for services without restart and already proposed in #133 You can add you contribution here.
the JDK path should be appended to the end of System's PATH The Windows team at Microsoft, they let us know internally :-).
There is usage for both prepend and append. I think, it depends. If we wanted to continue that a new JDK installed take precedence on older, this is the only solution at this time as we don't have shim binaries. Shim binaries is probably a good idea but not easy to do well... but maybe Microsoft will dev this feature :)
If the user selects JAVA_HOME to be configured, the PATH variable should reference it - %JAVA_HOME%\bin. What the pro and cons for this? Pros are the java, javac and other tools can be immediately used from the Command Line.
It is the same as now with full path .. use JAVA_HOME in path don't allow more than now. You can already use java/javac immediately with the current path set.
(Re-posting my comment from Slack here, as requested)
As far as I know, it is not recommended to prepend anything before C:\Windows\system32;C:\Windows; ... - these should always go first.
I suspect the behaviour of the ‘last thing I installed takes over’ is the principal of least surprise and so users are happy enough?
As an end-user, I would expect that Adoptium would be either added after C:\Windows; ... or at the end of the PATH.
Ideally, there should be a 'Take over' checkbox, which would control that behaviour.
(With 'Take over' set the JDK/JRE should be the first entry after C:\Windows\system32;C:\Windows; ..., without it - the last entry, i.e. APPEND method. Also an average end-user may expect this to set JAVA_HOME and Javasoft Registry keys as well, but this is is out of the scope of this question:) )
An hour of debugging why kinit and klist didn't behave properly led me to this thread here. Is there any traction on this?
Breaking from the expected behaviour of every other Vendor of OpenJDK is probably ill advised in this case. One option could be to add a flag to the installer to allow the user to override the default behaviour. We would happily consider a PR on this from the community.