bazel run doesn't honor --javabase, uses internal Java version

[dan-cohn]

I'm using Java 11 and therefore have the following in my .bazelrc:
run --javabase=@bazel_tools//tools/jdk:remote_jdk11

For java_binary rules, this works great, causing them to run with JDK 11. However, when I do a bazel run on a springboot target, it always uses Java 1.8. I believe the reason is that it looks at JAVA_HOME, which is not taken from my environment but rather from the environment internal to the bazel server. I confirmed this by modifying springboot.bzl to echo JAVA_HOME. It gave me jdk1.8 even though my JAVA_HOME is pointing to jdk-11.

[plaird]

Thanks for reporting, we will look at this.

[plaird]

I just solved a similar issue for python execution of the dupe class checker script. It was using system python, but I found the way to invoke the python toolchain. I thought the same approach would work for this use case, doing the following: (these comments are references in springboot.bzl)

• add toolchains = ["@bazel_tools//tools/jdk:current_java_toolchain"], to the _springboot_rule definition
• use the toolchain object to look up the path info to the JDK, see the compute_python_executable function as an example
• substitute the JDK path in the bazel run script text (_run_script_template)

But the JDK toolchain is not quite there. Fortunately, in the last day it looks like they finally finished the Java toolchain work in Bazel master:
bazelbuild/bazel#4592

So it looks like this issue will be unblocked by the next Bazel release (Dec 2020 or later).

[plaird]

My previous comment neglected to mention that we are still targeting Bazel 1.2.1 and later for support. We use Bazel 1.2.1 to develop the springboot rule, and that is probably why the java toolchain is not working. Internally we use Bazel 3.x for our builds, and the toolchain is better supported. So we could either:

• drop support for older Bazels after some milestone release (e.g. 1.1)
• figure out a way to refer to the java toolchain, but not break 1.2.1 users

[plaird]

This open issue is mitigated to a degree by this new feature: launcher_script attribute #92

You can now tailor the launcher script as needed in your environment. That still won't automatically pick up java_base but it may be enough.

[plaird]

Also consider the usage of arg files for bazel run:

% javac --help
Usage: javac
where possible options include:
@ Read options and filenames from file

We have some services that expect certain JVM args at startup. We have docs that tell users to include an args file when invoking bazel run (export JAVA_OPTS='@theargsfile') but something automatic is needed.

[luangong]

rules_spring should honor the Java runtime version specified with the --java_runtime_version flag. See Configuring the JVM used to execute and test the code.