Bazel 7.0: Java Toolchain Resolution for Bazel Ignores Java Flags #19934
Comments
|
After further research, I found this interesting piece of information. Resolving @rules_java_builtin//toolchains:remotejdk_17 causes a reevaluation of @local_config_platform//:host and enqueues the evaluation with the new configurationKey that contains jdk_17. Here are the screenshots from the debugger. Please let me know if I am on the right or wrong path. |
|
As an aside, I wonder if this is the same problem that I raised here: bazelbuild/rules_java#148. If so, maybe mine is in the wrong place? 🤔 |
|
Yes, I think this is identical to bazelbuild/rules_java#148. I don't fault you for that as the relevant code is still spread over both Bazel and rules_java :-) For any given Java build, there are generally two Java runtimes in use:
Running the Java compiler on a recent JDK is generally a good idea as it should give the best build performance. Since Bazel relies on the I haven't tried this myself yet, but just based on |
At the risk of making this thread somewhat convoluted to follow, I'll try to summarise what I believe my current problem is:
I don't know why you can't specify both Also, as a side note:
This confused me at first because we are using Bazel 6.4.0 and getting Java 21 by default. But then I changed the version of Bazel to 6.3.2 and found that |
|
The issue appears to be because whatever is in _BASE_TOOLCHAIN_CONFIGURATION's java_runtime is taking precedent. If you change java_runtime = Label("//toolchains:remotejdk_17") to java_runtime = Label("@bazel_tools//tools/jdk:remote_jdk11") You will get everything to compile against 11. In rules_java@7.0.4, this got changed to jdk21. Hopefully this helps. |
|
Dumping the default_java_toolchain.bzl, here is the problem: I'll spare you the full read but for toolchain_java{8,9,10,11}, the toolchain defaults to jdk 17 on runtime. The fix is probably very simple as injecting the right runtime parameter into each of the default_java_toolchain declarations for each individual version of Java. We are testing a fix for this and can upstream it in a few hours, if not tomorrow. It would be good to get this in for Bazel 7.0. |
|
@EdbertChan, I am actually interested in the full read, having banged my head on the issue for quite a while. My fix was to use a local toolchain (and also nonprebuilt, but that addressing a different issue) default_java_toolchain(
name = "nonprebuilt_toolchain_java" + str(version),
configuration = NONPREBUILT_TOOLCHAIN_CONFIGURATION,
java_runtime = "@local_jdk//:jdk",
source_version = str(version),
target_version = str(version),
)
for version in range(8, 31)Tuning the version of java in JAVA_HOME finally got rid of the issue. Is it fair to say that the issue resides in this single # Default java_toolchain parameters
DEFAULT_TOOLCHAIN_CONFIGURATION = _BASE_TOOLCHAIN_CONFIGURATION
_BASE_TOOLCHAIN_CONFIGURATION = dict(
...,
java_runtime = Label("//toolchains:remotejdk_21"),
) |
|
I would not recommend you use your fix nor upstream it for multiple reasons.
But we will get some compile time issues where certain java_tools fail to unzip external artifacts (I have not looked too deeply at this and sidestepped the issue).
because you will get
Unfortunately, that means the rules_java maintainers will have to get involved and supply a backward fix for every version of Java toolchain that has this JavaRuntimeInfo. But really, this is the proper way to fix the issue. I will leave a note in the rules_java on how to fix this.
The biggest drawback is that we cannot use the aformentioned because those will fail at Android compile time. Probably because the Android tools themselves were compiled against 17 (again, have not looked at this one too deeply). This is the one with the least blast radius and the most stable without getting too involved. Because of Java backwards compatibility, there should be no problem running Java 11- code on Java 11. Furthermore, in default_toolchain, the java_runtime parameter will override what is in the DEFAULT_TOOLCHAIN_CONFIGURATION. We have verified this by using
and checked the toolchain message at the top. We also looked at the compile messages themselves and verified they were using exec /external/remotejdk_11. Hope this helps! |
|
@EdbertChan Could you file a separate issue for 4.? Compiler error messages breaking the worker protocol sounds bad. I am not entirely sure what is supposed to be the bug here: Major versions of Bazel are generally free to update the compilation JDK and if you as a user would like to use a specific one (e.g. to enable faithful If Android breaks with this setup, then that is definitely a (separate) bug to solve. |
hvadehra
added
P2
Description of the bug:
To set and pin the Java toolchain to Java 11, Google documentation says to use
We observe that Bazel will not respect these flags in 7. However, this configuration works in Bazel 6.4.0.
Which category does this issue belong to?
No response
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
See branch at https://github.com/EdbertChan/SimpleBazelAndroidApp/tree/demonstrate_bazel_7_aquery
Which operating system are you running Bazel on?
MacOS
What is the output of
bazel info release?release 7.0.0-pre.20230906.2
If
bazel info releasereturnsdevelopment versionor(@non-git), tell us how you built Bazel.No response
What's the output of
git remote get-url origin; git rev-parse master; git rev-parse HEAD?No response
Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.
Yes. Last worked on Bazel 6.4
Have you found anything relevant by searching the web?
N/A
Any other information, logs, or outputs that you want to share?
When running with --toolchain_resolution_debug=., it looks like the resolution is overwritten at the last moment.
For instance, the log will be filled with
INFO: ToolchainResolution: Target platform @local_config_platform//:host: Selected execution platform @local_config_platform//:host, type @bazel_tools//tools/jdk:runtime_toolchain_type -> toolchain @remotejdk11_macos_aarch64//:jdkBut then the resolution gets set to remotejdk17. This does not make sense: it actually rejects the remotejdk11_macos_aarch64 when it has previously accepted and selected it.
Here is a portion of the toolchain debug:
The text was updated successfully, but these errors were encountered: