commit 8db450f0f21e445a8475f3f143bbf35ada1b4f5f
author Philipp Wollermann <philwo@google.com> Sun Feb 03 09:26:07 2019 -0800
committer Copybara-Service <copybara-piper@google.com> Sun Feb 03 09:28:08 2019 -0800
tree f48f1a62b7e72873b1403718cfa10846efc9fbe3
parent b430df1e0ba5b3ba0378c678dc62029bed711bfb

Fix #7304: Validate that JAVA_HOME points to a JDK.

If JAVA_HOME is not valid, fallback to the detection by looking up the
`javac` binary.

This also fixes an issue where Bazel would try to look up the boot classpath
for JDK 8 in the wrong folder: By convention, OpenJDK 8 has a directory
structure, where the JRE is in a subdirectory of the JDK:

/usr/lib/jvm/java-8-openjdk-amd64 <- JDK
/usr/lib/jvm/java-8-openjdk-amd64/jre <- JRE

This changed with OpenJDK 9 and newer and there is no longer a `jre`
folder for these versions (and newer Java versions are not supplied as a
separate "JRE" version anymore, there is only a "JDK").

On some platforms (e.g. Debian) the JAVA_HOME of an installed OpenJDK 8
might point to the JRE instead of the JDK, which triggers a bug in the
boot classpath detection logic in Bazel's DumpPlatformClassPath tool:
The tool relies on the directory structure as mentioned above to
determine whether it is looking at a OpenJDK 8 or OpenJDK >= 9. If
certain well-known files (e.g. "jre/lib/rt.jar") of OpenJDK 8 don't
exist, it assumes that it's looking at an OpenJDK 9+ - unfortunately
this is also the case when you're looking at something that's not a JDK
at all or the `jre` subfolder of an OpenJDK 8.

This triggers an InvalidArgumentException in the Javac code.

By making sure that we only ever pass a valid JDK path to that tool, the
problem can no longer happen.

RELNOTES: Bazel now validates that JAVA_HOME points to a valid JDK and
falls back to auto-detection by looking up the path of `javac`.

Closes #7324.

PiperOrigin-RevId: 232197212