Confluent CLI should check JAVA_HOME

[ybyzek]

Symptoms:

> java -version 2>&1 | head -1
java version "11.0.2" 2018-10-16 LTS

> $JAVA_HOME/bin/java -version 2>&1 | head -1
java version "1.8.0_201"

> export JAVA_HOME

> bin/confluent start
This CLI is intended for development only, not for production
https://docs.confluent.io/current/cli/index.html

Current Java version '11' is unsupported at this time. Confluent CLI will exit.

WARNING: Java version 1.8 is recommended. 
See https://docs.confluent.io/current/installation/versions-interoperability.html

Source of problem:

bin/confluent appears to have a routine called validate_java_version which just runs java without checking JAVA_HOME

Suggested fix:

Confluent CLI should check JAVA_HOME to enable confluent-cli to use a different JDK.

Temporary workaround:

Since Confluent CLI is a bash script, edit $CONFLUENT_HOME/bin/confluent directly

[kkonstantine]

The fact that JAVA_HOME points to a different JDK version than the java command that is found in your PATH of executable (bin) commands reveals a misconfiguration of java in your system, not a bug here.

Initially we made the decision not to try and guess which exactly java version a user needs to use. Before changing the code in Confluent CLI you should consider one of the several options to set the default java, depending on your operating system. A few examples are:

• update-java-alternatives
• jenv
• set both JAVA_HOME and PATH to point to the same JDK version
• other options ...

Another advantage of using the java that is found in your PATH instead of your JAVA_HOME (again it's the user's responsibility to have these settings point to the same JDK) is that the chances of java and sudo java being the same are higher.

Nevertheless, given that most java services in Confluent platform check first if JAVA_HOME is set we could extend Confluent CLI to do the same and align it with what the rest of the services do.

[rocketraman]

The fact that JAVA_HOME points to a different JDK version than the java command that is found in your PATH of executable (bin) commands reveals a misconfiguration of java in your system, not a bug here.

This is incorrect. It is not uncommon to have multiple versions of java installed on a system, and for program (a) to require a different version than program (b). Only one of these can be the "system java" which will run by default when executing java from the PATH. Using the alternatives mechanism changes the JVM for every process, not just the process that is the odd-man-out and needs an older version of the JDK for some reason (such as Confluent).

This is the whole reason why so many scripts, including Kafka itself as well as the run scripts produced by gradle, as well as gradle and maven and pretty much every other java-launching shell script on the planet, consult JAVA_HOME before falling back to the system java on the PATH -- to allow for the user to tell a particular process to use a version of java different than the system java. If the world were simple and every process could just use the system default java, that would be great, but that's just not reality (and will be even less so now with the increased java release cadence).

I appreciate the "nevertheless" and the fix, but would like to emphasize this not a misconfiguration but completely intentional and a normal situation in the java world.

[kkonstantine]

Fixed by:
#118
Thanks for reporting.