Bazel@HEAD doesn't support Java 10 any more. The tool chain is extended
to support building with Java 10 using host_javabase option and vanilla
java builder. To use --host_javabase option we have to provide absolute
path to the JDK 10. To keep that non-portable part out of the build file
we use variable that is substitued during build invocation. Say, the
location of the JDK 10 is: /usr/lib64/jvm/java-10, then the build is
invoked with:
$ bazel build --host_javabase=:absolute_javabase \
--define=ABSOLUTE_JAVABASE=/usr/lib64/jvm/java-10 ...
Given that absolute_javabase rule is not a part of released Bazel yet,
but will be only included in future Bazel releases, we have to add it in
our own build file:
java_runtime(
name = "absolute_javabase",
java_home = "$(ABSOLUTE_JAVABASE)",
visibility = ["//visibility:public"],
)
While this works, it fails the Gerrit-CI, because recently it was
changed to exercise //... rule, and cannot resolve ABSOLUTE_JAVABASE
variable, because it wasn't provided in the CI environment. CI is still
using Java 8.
One approach to address that problem would be to use "manual" tag for a
rule that would exclude it from generic targets like //..., but
unfortunately, java_runtime rule doesn't expose tag attribute.
The next workaround is to hide that variable behind a select statement.
This is a harmless hack:
config_setting(
name = "use_absolute_javabase",
values = {"define": "USE_ABSOLUTE_JAVABASE=true"},
)
java_runtime(
name = "absolute_javabase",
java_home = select({
":use_absolute_javabase": "$(ABSOLUTE_JAVABASE)",
"//conditions:default": "",
}),
visibility = ["//visibility:public"],
)
Now from the CI the rule: //:absolute_javabase would produce non working
java_runtime, because java_home wasn't specified, but given that this
java_runtime is not used during the build, it doesn't matter. Add also
a TODO comment to replace that interim solution when absolute_javabase
is supported in released Bazel version. As the consequence for hiding
that rule behind a condition, we need to provide additional variable so
that Bazel can correctly resolve java_home in java_runtime rule:
$ bazel build --host_javabase=:absolute_javabase \
--define=ABSOLUTE_JAVABASE=/usr/lib64/jvm/java-10 \
--define=USE_ABSOLUTE_JAVABASE=true [...]
Also extend tools/eclipse/project.py to accept Java 10 specific options.
There is already --java <jdk number> option that was added recently to
support Eclipse .classpath generation when JDK 9 is used, but this can
not be used, because for Java 10 we have to provide absolute path to the
Java 10 location. Add new option --edge_java where all Java 10 specific
options can be passed:
$ tools/eclipse/project.py --edge_java \
"--host_javabase=:absolute_javabase \
--define=ABSOLUTE_JAVABASE=/usr/lib64/jvm/java-10 \
--define=USE_ABSOLUTE_JAVABASE=true \
--host_java_toolchain=//:toolchain_vanilla \
--java_toolchain=//:toolchain_vanilla"
Alternative approach would be to add those options to Bazel resource
file.
Test Plan:
$ bazel build --host_javabase=:absolute_javabase \
--define=ABSOLUTE_JAVABASE=/usr/lib64/jvm/java-10 \
--define=USE_ABSOLUTE_JAVABASE=true \
--host_java_toolchain=//:toolchain_vanilla \
--java_toolchain=//:toolchain_vanilla \
:release
and replace ABSOLUTE_JAVABASE variable with the location of JDK 10.
To verify that major version of generated classes is 54, use:
$ $JAVA_HOME/bin/javap -verbose \
-cp bazel-bin/java/com/google/gerrit/common/libserver.jar \
com.google.gerrit.common.data.ProjectAccess | grep "major version"
54
[1] https://github.com/bazelbuild/bazel/issues/6012
Change-Id: I5e652f7a19afbcf3607febd9a7a165dc07918bd0
f55b69f5c9