Java runtime mismatch (JDK 11 instead of JDK 8) on Bazel@HEAD

[davido]

On most recent Bazel@HEAD (eb53de2), after building with Java 8, the final artifact doesn't run, because it is producing java version 55:

  $ b10 build --incompatible_string_join_requires_strings=false --incompatible_use_python_toolchains :release
  Target //:release up-to-date:
  bazel-bin/release.war
INFO: Elapsed time: 345.764s, Critical Path: 152.76s
INFO: 1476 processes: 648 linux-sandbox, 7 local, 821 worker.
INFO: Build completed successfully, 2257 total actions

  $ java -jar bazel-bin/release.war init -d ../test_site_xxx_yyy_zzz
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.UnsupportedClassVersionError: Main has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
	at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:495)

I am using Java 8:

  $ $JAVA_HOME/bin/java -version
  openjdk version "1.8.0_212"
OpenJDK Runtime Environment (IcedTea 3.12.0) (build 1.8.0_212-b4 suse-1.1-x86_64)
OpenJDK 64-Bit Server VM (build 25.212-b04, mixed mode)

To reproduce on Gerrit Code Review run:

  $ b10 build java/com/google/gerrit/common:server
  INFO: Analyzed target //java/com/google/gerrit/common:server (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
Target //java/com/google/gerrit/common:server up-to-date:
  bazel-bin/java/com/google/gerrit/common/libserver.jar
INFO: Elapsed time: 0.693s, Critical Path: 0.26s
INFO: 0 processes.
INFO: Build completed successfully, 1 total action

And then check java version:

  $ javap -verbose -cp bazel-bin/java/com/google/gerrit/common/libserver.jar \
     com.google.gerrit.common.data.SubscribeSection | grep major
    major version: 55

[davido]

I narrowed the problem down to switching to alternative toolchain in bazelrc file, with all warnings enabled per default:

diff --git a/.bazelrc b/.bazelrc
index d6d4ce6cd3..4a89eed7c9 100644
--- a/.bazelrc
+++ b/.bazelrc
@@ -3,7 +3,6 @@ build --repository_cache=~/.gerritcodereview/bazel-cache/repository
 build --experimental_strict_action_env
 build --action_env=PATH
 build --disk_cache=~/.gerritcodereview/bazel-cache/cas
-build --java_toolchain //tools:error_prone_warnings_toolchain
 
 test --build_tests_only
 test --test_output=errors

The error prone toolchain is defined here: https://gerrit.googlesource.com/gerrit/+/refs/heads/master/tools/BUILD#16.

@cushon @iirina @meisterT Any clue why target java version is swapped to 55 in this case?

[davido]

Update: I don't see this problem on Bazel 0.26.0. In case it's relevant how I'm building Bazel from HEAD:

  $ bazel build src:bazel-bin-dev

[iirina]

@davido Thanks for the bug report. I'll take a closer look later this week.

[davido]

@iirina I have bisected the problem. The offending commit is: bad5a2b.

[iirina]

Thanks @davido. That's what I suspected as well. I'm trying to understand why bad5a2b caused this regression. By looking at how //tools:error_prone_warnings_toolchain is defined, the artifact should have been built for major version 53 with bazel 0.26.

I'm still looking into why the regression happened to come up with a proper fix.

If you are blocked by this you can add

source_version = "8",
target_version = "8",

to your toolchain definition.

[davido]

By looking at how //tools:error_prone_warnings_toolchain is defined, the artifact should have been built for major version 53 with bazel 0.26.

You mean major version 52, right? With 0.26 the produced byte code is correct and is major version 52.

[iirina]

I actually meant 54 because the javac version used by Bazel 0.26 comes from JDK 10.

The jar's major version with bazel@head comes from the javac version used (i.e. java 11 -> 55).
I can't figure out why the artifact major version with bazel 0.26 is 52. The javac version is 10 (54) and there are no source_version and target_version attributes specified on the java_toolchain in use.

[cushon]

Oh, for some reason I though default_java_toolchain defaulted to {source,target}_version = 8.

The previous javac version had a non-standard modification to default to the Java 8 language level, which wasn't carried forward to 11. That explains the change.

[iirina]

Thanks @cushon for the explanation. The default java_toolchain used by Bazel uses {source,target}_version = 8 but it's not hard-coded into default_java_toolchain itself. We can make it the default to keep backwards compatibility, although this is not really a bazel regression.

@davido does adding {source,target}_version = 8 to the //tools:error_prone_warnings_toolchain work for gerrit?

[laurentlb]

Let me know what needs to be cherrypicked for 0.27.