Respect rules_java as the source of truth for java toolchains Context: https://github.com/bazelbuild/bazel/discussions/18373 Currently the definitions of java tools, remote JDKs, and Java toolchains are duplicated in both Bazel sources and rules_java, and they go out of sync quite often. By default, the default toolchains shipped with the Bazel binary uses the one in Bazel sources except when Bzlmod is enabled. https://github.com/bazelbuild/rules_java/pull/110 syncs java toolchain related files from Bazel sources to rules_java and this PR removes most of the definitions in Bazel source and uses rules_java as the source of truth. Significant changes in this PR: - Removed all java tools definitions from distdir_deps.bzl - Removed all remote JDK definitions from distdir_deps.bzl except the ones for to be embedded within Bazel binary. - Changed `jdk.WORKSPACE.tmpl` to load java tools and JDKs from rules_java as WORKSPACE suffix. - Removed the `jdk_http_archives` hack for some shell tests. That dates back to https://github.com/bazelbuild/bazel/pull/8361, I don't think it's needed since we have the WORKSPACE suffix by default. - When building Bazel with Bazel, we were using the java toolchains shipped in `@bazel_tools` of the Bazel binary, now we use the java toolchains from the `rules_java` defined in distdir_deps.bzl. This enables us to build Bazel itself with the latest java toolchain, therefore can detect issues earlier. - Removed `_for_testing` suffixes for the shared repo hack for Bazel CI since the java tools and remote JDKs versions we load to build Bazel are the same as the ones shipped in the Bazel binary we built (via `jdk.WORKSPACE.tmpl`) and used in the integration tests. They all come from the rules_java version in distdir_deps.bzl. - Removed the `test_WORKSPACE_files` hack for `workspace_resolved_test.sh`. - Mocked rules_java in some integration tests to avoid needing to download it or its transitive dependencies. Breaking changes: - Loading `.bzl` files under `@bazel_tools//tools/jdk` in WORKSPACE now requires you to define `rules_java` in advance, the `rules_java` definition in WORKSPACE suffix cannot guarantee `@rules_java` exist because it's appended after the content of the user WORKSPACE file. Closes #18423. RELNOTES[INC]: Loading `.bzl` files under `@bazel_tools//tools/jdk` in WORKSPACE now requires `rules_java` to be defined in advance. PiperOrigin-RevId: 536682532 Change-Id: Ia7475bfe134729ab1592b0ef0a31d28eb839b5ac
{Fast, Correct} - Choose two
Build and test software of any size, quickly and reliably.
Speed up your builds and tests: Bazel rebuilds only what is necessary. With advanced local and distributed caching, optimized dependency analysis and parallel execution, you get fast and incremental builds.
One tool, multiple languages: Build and test Java, C++, Android, iOS, Go, and a wide variety of other language platforms. Bazel runs on Windows, macOS, and Linux.
Scalable: Bazel helps you scale your organization, codebase, and continuous integration solution. It handles codebases of any size, in multiple repositories or a huge monorepo.
Extensible to your needs: Easily add support for new languages and platforms with Bazel's familiar extension language. Share and re-use language rules written by the growing Bazel community.
Follow our tutorials:
To report a security issue, please email security@bazel.build with a description of the issue, the steps you took to create the issue, affected versions, and, if known, mitigations for the issue. Our vulnerability management team will respond within 3 working days of your email. If the issue is confirmed as a vulnerability, we will open a Security Advisory. This project follows a 90 day disclosure timeline.
See CONTRIBUTING.md
