is it possible to force ES to use the bundled JDK instead of the one pointed by JAVA_HOME?
In some environments, elder version of JAVA is already installed and used by other applications, and customers may refuse to upgrade it centrally because of ES.
(Windows / Installed as a service by msi)
Disclaimer: I am no windows expert, so feel free to fully ignore my advice. Under other operating systems, unsetting JAVA_HOME would work, and checking the scripts under the bin directory in Elasticsearch the behaviour for windows seems to be the same.
In Windows, the elasticsearch.exe is started as a service, but it seems that it does not call elasticsearch-env.bat during this, that would set up the paths. It seems to always prefer JAVA_HOME coming from the process user, that is LocalSystem by default. And this is the problem, because in this case, I should remove the JAVA_HOME on system level (that is not acceptable) or always create a dedicated user for ES service (and set JAVA_HOME on user level) => overhead in most cases. The simplest solution would be adding a config file to elasticsearch.exe, and letting you configure a custom java path there, that would be checked first.
Hey @mesztam, it sounds like you're using the Windows MSI installer, based on the installation of an elasticsearch.exe. The installer is configured to use the bundled JDK from version 7.3.0 onwards.
Prior 7.x versions of the installer require JAVA_HOME to be set at installation time, or for a version of Java to be detected in the registry. In these versions, it is possible to have elasticsearch.exe use the bundled JDK by
Installing Elasticsearch with the MSI, but not installing as a Windows service
updating JAVA_HOME to point to the location of the bundled JDK
Registering elasticsearch.exe as a Windows service with
sc.exe create Elasticsearch type= own start= auto binpath= "C:\Program Files\Elastic\Elasticsearch\<version>\bin\elasticsearch.exe" displayname= Elasticsearch
Maybe it would fall back to the bundled JDK, if I would remove adoptopenjdk from path/java_home, but in a prod environment where potentially other software using java are also installed, this cannot be done.
It's intended to work like this; if JAVA_HOME environment variable it set, it will use that, and if it is not set, it will use the bundled JDK. This is to allow a user to override using the bundled JDK by explicitly setting JAVA_HOME.
I understand that, but in windows environment, if you run it as a service, you cannot override the JAVA_HOME only for the service. I can delete it only on system-level, making all other JAVA applications non-working. I can imagine that in linux environment, you can clear the java_home for this specific process on startup in a shell script or so, but in windows, you cannot do this for a windows service.
In many environments, JAVA is already installed and other java apps are running on the server, thus JAVA_HOME is set to some java folder (maybe even 32 bit or old), but if this JAVA version is not sufficient for ES, then I have no choice but 1) upgrading the system-installed JAVA to a newer one, risking that I make other java apps non-working. OR I remove JAVA_HOME (to let ES fall back to the bundled JDK), but then again, all other JAVA apps will stop working. Do you see what I mean?
I think, if you already bundle ES with JDK, the default should be using the bundled JDK. And using another one only on demand (e.g. if you delete the jdk folder, then it could fall back to JAVA_HOME). Or even simpler would be checking for some specific dedicated env. variable, like "ES_JAVA_HOME", and if it set, then use it, and try all the other options only after this.
Just an extension: this is already a problem during the installation (via msi), because the installer already does some jobs (e.g. plugin install) via java. And if you have an incompatible JAVA version on your system, then the installer already crashes because of this.