Java Toolchain Changes

[Gunnar Wagenknecht]

Greetings Bazel Dev Team,

Is there a doc to read more about the recent changes to java toolchains? We used to define our own toolchain with --java_toolchain to make use of the Eclipse JDT compiler. I'm trying to get that working in Bazel 5. There seems to be quite a few changes needed and I'm trying to learn what adaptions I have to do.

It seems that --java_toolchain has been replaced with --extra_toolchains. Is my interpretation correct that it's solely depending on the version number, which toolchain is being used? What happens if there are two toolchain definitions for the same Java version? Which one will be selected?

The example here:
https://bazel.build/docs/bazel-and-java#config-java-toolchains

Defines a default_java_toolchain with name = "repository_default_toolchain". The --extra_toolchains argument contains an additional "_definition" suffix. Is this required or a typo?

It looks like this is required. I got passed an error after adding the "_definition" to register_toolchain as well. Maybe this should be documented.

Another question, the java_runtime on default_java_toolchain seems to always point to remote jdks.
java_runtime = "@bazel_tools///tools/jdk:remote_jdk11"

I read in the docs I can force the local JDK with "--extra_toolchains=@local_jdk//:all". That seems to register an additional toolchain for the local JDK, which is then selected by Bazel for compilation. That agains seems confusing as I now have multiple defined and I'm not sure which one would be picked by Bazel for compilation. How would I force the local jdk for compilation with my own default_java_toolchain as defined above?

-Gunnar

--
Gunnar Wagenknecht
gun...@wagenknecht.org, http://guw.io/

[Jingwen Chen]

+Ivo Ristovski List 

--
You received this message because you are subscribed to the Google Groups "bazel-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-dev/EFB143F4-26E9-4CD3-86CD-B6166F29AA2F%40wagenknecht.org.

[Jared Neil]

We also ran into some trouble with this transition. Eventually we got the local JDK working, but quickly discovered that bazel was including more files in the JDK than it used to, and some of those files were not consistent across machines, so we couldn't get any cache hits between machines.  We decided to switch to a remote_java_repository to get cache hits again. This is what we ended up with:

WORKSPACE:

remote_java_repository(

name = "remote_jdk8_linux",

exec_compatible_with = [

"@platforms//os:linux",

"@platforms//cpu:x86_64",

],

sha256 = "ea4723c53a534bcb474b2915149cdca549fbcfebeb1b05b3465aa09ad9c6d3a4",

strip_prefix = "amazon-corretto-8.322.06.2-linux-x64",

url = "https://corretto.aws/downloads/resources/8.322.06.2/amazon-corretto-8.322.06.2-linux-x64.tar.gz",

version = "8",

)

register_toolchains("//:repository_default_toolchain_definition")

BUILD.bazel:

load("@bazel_tools//tools/jdk:default_java_toolchain.bzl", "JVM8_TOOLCHAIN_CONFIGURATION", "default_java_toolchain")

default_java_toolchain(

name = "repository_default_toolchain",

configuration = JVM8_TOOLCHAIN_CONFIGURATION,

java_runtime = "@bazel_tools//tools/jdk:java_runtime_alias",

misc = [

"-XDskipDuplicateBridges=true",

"-XDcompilePolicy=simple",

"-g",

"-parameters",

],

source_version = "8",

)

.bazelrc:

build --java_language_version="8"

build --java_runtime_version="remotejdk_8"

build --tool_java_language_version="8"

build --tool_java_runtime_version="remotejdk_8"