Upgrade Java runtime to 21 while keeping the compiler toolchain as 17

[yzhangyext]

Version:
Bazel: 7.2.1
rules_java: 7.1.0

Hi team, we are planning to upgrade our bazel Java version to 21 in two steps, upgrading runtime first, followed by the toolchain compiler upgrade. I am now stuck at making the configuration work for Java 21 runtime while keeping the toolchain version as 17, Our current setting with Java 17 in Bazel is, set these flags in .bazelrc

build --java_runtime_version=remotejdk_17
build --tool_java_runtime_version=remotejdk_17
build --java_language_version=17
build --tool_java_language_version=17

Then register a toolchain with "default_java_toolchain"

default_java_toolchain(
    name = "toolchain_jdk_17",
    java_runtime = "@bazel_tools//tools/jdk:remotejdk_17",
    source_version = "17",
    target_version = "17",
    # other params
)

My first attempt was to bump these two flags as

build --java_runtime_version=remotejdk_21
build --tool_java_runtime_version=remotejdk_21

However I was seeing some build errors like

error: [BazelJavaConfiguration] The Java 17 runtime used to run javac is not recent enough to compile for the Java 21 runtime in external/remotejdk21_macos_aarch64. Either register a Java toolchain with a newer java_runtime or specify a lower --tool_java_runtime_version.
...
error: cannot access module-info
  bad class file: /modules/java.security.sasl/module-info.class
    class file has wrong version 65.0, should be 61.0
    Please remove or make sure it appears in the correct subdirectory of the classpath.

Then I go ahead and also change the java_runtime field within default_java_toolchain:

default_java_toolchain(
    name = "toolchain_jdk_17",
    java_runtime = "@rules_java//toolchains:remotejdk_21",
    source_version = "17",
    target_version = "17",
    # other params
)

That makes the build pass, however I noticed the java compiler was actually 21 as well, while I expected it to stay 17, because I added some code related to VirtualThread and they were compiled successfully.

Did I make any mistakes in my configurations? Appreciate any pointers and tips.

[hvadehra]

This looks like https://github.com/bazelbuild/bazel/discussions/21769 and will possibly be fixed by https://github.com/bazelbuild/rules_java/pull/182. Could you try building by overriding rules_java to the state of that PR?

[yzhangyext]

Hi, thanks for the quick fix! However I am having some trouble applying this change: upgrading to rules_java v8 will break our existing protobuf settings. I tried cherry-picking that change on top of version 7.12.4, but building with the --@rules_java//java:incompatible_language_version_bootclasspath flag didn't change the bootclasspath behavior. Do you know if that change could be backported to version 7?

[hvadehra]

However I am having some trouble applying this change: upgrading to rules_java v8 will break our existing protobuf settings

• What is your Bazel version?
• Are you using bzlmod (x)or WORKSPACE?
• What version of protobuf are you currently on?

[JohnnyMorganz]

Hi, we are also interested in using the new flag --@rules_java//java:incompatible_language_version_bootclasspath, but we are currently on Bazel 7.5.0.

We are currently bringing in rules_java via bzlmod (on 7.6.5), but we are still in the middle of our bzlmod migration. I tried a brief attempt to update to 8.8.0 but hit the issue similar to https://github.com/bazelbuild/rules_java/issues/256 (probably because we aren't fully migrated from WORKSPACE yet)

ERROR: Failed to load Starlark extension '@@compatibility_proxy//:proxy.bzl'.
Cycle in the workspace file detected. This indicates that a repository is used prior to being defined.
The following chain of repository dependencies lead to the missing definition.
 - @@compatibility_proxy
This could either mean you have to add the '@@compatibility_proxy' repository with a statement like `http_archive` in your WORKSPACE file (note that transitive dependencies are not added automatically), or move an existing definition earlier in your WORKSPACE file.
ERROR: Error computing the main repository mapping: cycles detected during computation of main repo mapping

Is it feasible to backport this feature to 7.x?

(Also, it's not completely clear to me if using rules_java 8.x whilst still on Bazel 7.x is a valid configuration, not entirely sure if there's any compatibility issues there)

[hvadehra]

I tried a brief attempt to update to 8.8.0 but hit the issue similar to https://github.com/bazelbuild/rules_java/issues/256 (probably because we aren't fully migrated from WORKSPACE yet)

The latest rules_java releases should work fine with Bazel 6.4.0+. See the release notes for the small changes needed in your WORKSPACE file: https://github.com/bazelbuild/rules_java/releases/tag/8.8.0 (as always with the WORKSPACE mechanism, please note that you may need to newly introduce the stanza(s) specified there or rearrange existing ones to enforce the the right version and instantiation order)

[JohnnyMorganz]

Thanks for the quick reply! To be clear we are bringing in rules_java via bzlmod, not workspace, with bazel_dep(name = "rules_java", version = "7.5.0"). But it seems to still hit the error above after bumping the version.

I guess because something else in workspace is trying to pull in rules_java as well. Maybe I still need to keep the workspace snippet even though we bring rules_java via bzlmod? Not sure, will keep trying to play with this, thanks.

[hvadehra]

Yes, I think you'll need to have the rules_java WORKSPACE snippet as well. Preferable add it to the top to avoid issues.