[7.0.0] Fix Java runtime toolchain resolution in cross-compilation scenarios #19900
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The Java rules used toolchains of type
@bazel_tools//tools/jdk:runtime_toolchain_type
for two different purposes requiring different exec/target platform constraints, which led to issues when cross-compiling: The runtime added to the runfiles of an executable Java target has to have constraints on the target platform, whereas the runtime used to extract the bootclasspath should not have constraints on the target platform. As a result:@local_jdk
did not define any target constraints for its runtime, which allowed the runtime to provide the bootclasspath required by Android rules, but could also end up buildingjava_binary
targets that wouldn't run on the target (see Bazel treats local_jdk as a "can run anywhere" toolchain #18265).This is resolved by adding a third toolchain type,
bootstrap_runtime_toolchain_type
, that is only used by thebootclasspath
rule (realizes #17085 (comment)). Detailed explanations of the different types and their intended constraints have been added to@bazel_tools//tools/jdk:BUILD
.Addressing the cross-compilation errors then required the following changes:
android_library
andjava_binary
withcreate_executable = False
).bootclasspath
rule have been replaced with dependencies on the bootstrap runtime.{local,remote}_java_repository
now use the user-provided exec constraints of the Java toolchain as the target constraints of the associated runtime.@local_jdk
uses the auto-detected host constraints as exec constraints for the local Java toolchain.Fixes #17085
Fixes #18265
Fixes bazelbuild/rules_java#64
RELNOTES[INC]: Java runtime toolchains created via
local_java_repository
from@bazel_tools//tools/jdk:local_java_repository.bzl
, which includeslocal_jdk
, now havetarget_compatible_with
set to the auto-detected host constraints. This can result in errors about toolchain resolution failures for@bazel_tools//tools/jdk:runtime_toolchain_type
, especially when cross-compiling. These failures can be fixed in the following ways (listed in decreasing order of preference):java_binary
targets that aren't meant to be run withbazel run
or as tools during the build withjava_single_jar
(available in@rules_java//java:java_single_jar.bzl
). Such targets do not require a Java runtime for the target configuration.--java_runtime_version=remotejdk_N
for some Java versionN
to let Bazel choose and download an appropriate remote JDK for the current target platform. This setting defaults tolocal_jdk
, which means that Bazel can only use the local JDK, which isn't compatible with any other platform.local_java_runtime
with no value set forexec_compatible_with
(defaults to[]
) and select it by setting--java_runtime_version
to itsname
. This fully restores the previous behavior, but can result in incorrect results when cross-compiling (see Bazel treats local_jdk as a "can run anywhere" toolchain #18265).Closes #18262.
Commit f79ca02
PiperOrigin-RevId: 574914446
Change-Id: I6cbfb7ffa2fbfd62e5f6fb49532b36be658dfa40