You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some Java based services may rely only on the environment (e.g. JAVA_HOME, PATH) to invoke java. But services are invoked on the system account by (and inherit their environment from) services.exe which itself is only invoked at Windows start-up. So those environment variables (that are changed as an updated version of the JDK is installed) are not seen even if these services are restarted. These services will only start using the new JDK after a system reboot.
The Oracle JDK appears to sidestep this issue via the use of a single junction directory (one of C:\ProgramData\Oracle\Java\Javapath or C:\Program Files\Common Files\Oracle\Java\javapath or C:\Program Files (x86)\Oracle\Java\javapath) that links to a parallel directory (like javapath_target_<number>), created for each installed JDK, that only contains the java, javaw, and javaws launchers from that installed JDK.
I suspect the common junction directory is used so that the three launchers can be selected atomically whenever a new JDK is installed onto the system. When the launchers are run from this directory (i.e. not the ones in the actual JDK installation), they seem to just execute another java by looking up its location in a registry key (e.g.JavaHome under HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\1.8 ).
By simply putting this single junction directory onto the PATH, Java based services are easily switched to an updated JDK (once the registry key is updated) with only a restart (not requiring a reboot). In fact, this junction directory approach seems to work with the AdoptOpenJDK java launcher as well (which was predictable), but it does not work with the javaws launcher from IcedTeaWeb :( .
Because AdoptOpenJDK binaries just install directly to a directory (which then goes onto PATH and/or JAVA_HOME), users seem to be left with implementing their own junction directory approach themselves, or else accepting the reboot requirement in order to update their Java services, neither of which sounds very user friendly.
Have I missed some way that AdoptOpenJDK binaries can be updated and used as easily as the Oracle JDK ones, even when updating Java based services?
If not, would it be possible for the AdoptOpenJDK installer to enable JDK updates to be made in such a way that Java services can be simply restarted to use the updated JDK without requiring a reboot? It doesn't have to be via the junction directory mechanism used by the OracleJDK installer, but it would be nice if users didn't have to do it themselves. It would also be nice if it could work for all the launchers (even javaws).
The text was updated successfully, but these errors were encountered:
Have I missed some way that AdoptOpenJDK binaries can be updated and used as easily as the Oracle JDK ones, even when updating Java based services?
I've asked in the installer channel on our Slack.
mstoodle
changed the title
Update JDK for Java based WIndows services without requiring a reboot?
Update JDK for Java based Windows services without requiring a reboot?
Aug 13, 2019
Some Java based services may rely only on the environment (e.g.
JAVA_HOME
,PATH
) to invokejava
. But services are invoked on the system account by (and inherit their environment from)services.exe
which itself is only invoked at Windows start-up. So those environment variables (that are changed as an updated version of the JDK is installed) are not seen even if these services are restarted. These services will only start using the new JDK after a system reboot.For more detail, please see: https://support.microsoft.com/en-us/help/821761/changes-that-you-make-to-environment-variables-do-not-affect-services
The Oracle JDK appears to sidestep this issue via the use of a single junction directory (one of
C:\ProgramData\Oracle\Java\Javapath
orC:\Program Files\Common Files\Oracle\Java\javapath
orC:\Program Files (x86)\Oracle\Java\javapath
) that links to a parallel directory (likejavapath_target_<number>
), created for each installed JDK, that only contains thejava
,javaw
, andjavaws
launchers from that installed JDK.I suspect the common junction directory is used so that the three launchers can be selected atomically whenever a new JDK is installed onto the system. When the launchers are run from this directory (i.e. not the ones in the actual JDK installation), they seem to just execute another
java
by looking up its location in a registry key (e.g.JavaHome
underHKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\1.8
).By simply putting this single junction directory onto the
PATH
, Java based services are easily switched to an updated JDK (once the registry key is updated) with only a restart (not requiring a reboot). In fact, this junction directory approach seems to work with the AdoptOpenJDKjava
launcher as well (which was predictable), but it does not work with thejavaws
launcher from IcedTeaWeb :( .Because AdoptOpenJDK binaries just install directly to a directory (which then goes onto
PATH
and/orJAVA_HOME
), users seem to be left with implementing their own junction directory approach themselves, or else accepting the reboot requirement in order to update their Java services, neither of which sounds very user friendly.Have I missed some way that AdoptOpenJDK binaries can be updated and used as easily as the Oracle JDK ones, even when updating Java based services?
If not, would it be possible for the AdoptOpenJDK installer to enable JDK updates to be made in such a way that Java services can be simply restarted to use the updated JDK without requiring a reboot? It doesn't have to be via the junction directory mechanism used by the OracleJDK installer, but it would be nice if users didn't have to do it themselves. It would also be nice if it could work for all the launchers (even
javaws
).The text was updated successfully, but these errors were encountered: