[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_typefor 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_jdkdid 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_binarytargets 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 thebootclasspathrule (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_libraryandjava_binarywithcreate_executable = False).bootclasspathrule have been replaced with dependencies on the bootstrap runtime.{local,remote}_java_repositorynow use the user-provided exec constraints of the Java toolchain as the target constraints of the associated runtime.@local_jdkuses 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_repositoryfrom@bazel_tools//tools/jdk:local_java_repository.bzl, which includeslocal_jdk, now havetarget_compatible_withset 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_binarytargets that aren't meant to be run withbazel runor 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_Nfor some Java versionNto 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_runtimewith no value set forexec_compatible_with(defaults to[]) and select it by setting--java_runtime_versionto 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