Should we stop honoring JAVA_HOME in favor of a dedicated environment variable

[jasontedor]

Awhile ago, we stopped honoring generic environment variables. That is environment variables that have some convention in the community (but are not actually built in to the JVM). For example, we honor our own ES_JAVA_OPTS over JAVA_OPTS. A primary reason that we do this is to avoid conflicts where a user has set some values in JAVA_OPTS that they wouldn't want applying to Elasticsearch. Having a dedicated environment variable avoids surprises and actually simplifies administration (since it's rare to expect there to be a common JVM flag to apply to every JVM that might execute on a system).

Yet, we still honor JAVA_HOME which has the same pitfalls, where the system could have JAVA_HOME configured despite a user not necessarily wanting to use the system Java with Elasticsearch.

Should we drop honoring JAVA_HOME to give the user explicit control over which Java is used via a dedicated environment variable ES_JAVA_HOME (or, the bundled JDK if it is not set)?

[elasticmachine]

Pinging @elastic/es-core-infra (:Core/Infra/Packaging)

[serak]

it should first check if ES_JAVA_HOME is set if not then it should check for JAVA_HOME to detect which java version to use

[rjernst]

Also checking if JAVA_HOME exists would defeat the purpose of this change. Often an old version of java is installed by the OS, and JAVA_HOME exists. When this occurs, Elasticsearch sees JAVA_HOME and ignores the bundled jdk. That is the behavior that we want to avoid, by scoping the java environment variable to be "owned" by Elasticsearch. We would of course have a deprecation period where we would fall back to JAVA_HOME, but the ultimate goal is to stop using it.

[mark-vieira]

I vote we do this for 8.0. This increasingly makes sense with the removal of the no-jdk distribution. That way we can effectively always guarantee that a JDK will be available to fall back on if folks don't set ES_JAVA_HOME and we never have to look at JAVA_HOME.

[bytebilly]

I also agree we should change the behavior and use a dedicated variable instead for people that want to override the JVM.

In 7.x we can add ES_JAVA_HOME with higher precedence over JAVA_HOME, and write a deprecation warning in case the former is not set and the latter is set. This will cover possible "unintended" scenarios.

In 8.0 we will remove support for JAVA_HOME.

What do you think?

[mark-vieira]

I've opened #68848 to do "part 1" which is introduce the new environment variable and deprecate JAVA_HOME for 7.12. We'll follow up resolving this issue by removing the usage of JAVA_HOME entirely in 8.0.