-
Notifications
You must be signed in to change notification settings - Fork 86
Fix bootstrap_runtime_toolchain_type reference #215
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Closed
+1
−1
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mbland
added a commit
to EngFlow-Academy/bzlmod-bootcamp
that referenced
this pull request
Oct 28, 2025
Resolves the `_allowlist_function_transition` error under Bazel 6, since `rules_java` 7.10.0 adds it back in: - bazelbuild/rules_java#210: Make rules_java backwards compatible with Bazel 6.3.0 bazelbuild/rules_java@30ecf3f However, this version breaks `bootcamp_library` under Bazel 7, which currently uses `@bazel_tools//tools/jdk:toolchain_jdk_17`, with the following error: ```txt $ USE_BAZEL_VERSION=7.6.2 bazel build //... ERROR: external/rules_java_builtin/toolchains/BUILD:254:14: While resolving toolchains for target @@rules_java_builtin//toolchains:platformclasspath (096dcc8): No matching toolchains found for types @@bazel_tools//tools/jdk:bootstrap_runtime_toolchain_type. To debug, rerun with --toolchain_resolution_debug='@@bazel_tools//tools/jdk:bootstrap_runtime_toolchain_type' ``` The next commit fixes this error by replacing that toolchain dependency with `@rules_java//toolchains:toolchain_jdk_17` instead. This is another repo ordering problem related to the legacy `WORKSPACE` prefix from Bazel 7.6.2 instantiating `rules_java` 7.6.5 as `@rules_java_builtin`. - The legacy `WORKSPACE` prefix instantiates `rules_java_builtin` from `rules_java` 7.6.5, as explained in "Bump to Bazel 7.6.2". - Bazel creates a repo mapping from `@rules_java` to `@rules_java_builtin` for `@bazel_tools` in its legacy `WORKSPACE` prefix. https://github.com/bazelbuild/bazel/blob/7.6.2/src/main/java/com/google/devtools/build/lib/bazel/rules/GenericRules.java#L56-L57 https://github.com/bazelbuild/bazel/blob/7.6.2/src/main/java/com/google/devtools/build/lib/bazel/rules/tools.WORKSPACE#L1-L5 - The legacy `bootcamp/WORKSPACE` file instantiates `rules_java` 7.10.0. `rules_java_dependencies` instantiates its JDK toolchain repos using an updated `toolchain_type`, and `rules_java_toolchains` registers them. - The legacy `WORKSPACE` suffix invokes the `rules_java_dependencies` macro from `rules_java` 7.6.5. This does nothing, because `rules_java` wraps the remote JDK toolchain repo rules in a `maybe`, and repos of the same names already exist. - The `@bazel_tools//tools/jdk` toolchains transitively depend upon `@rules_java_builtin//toolchains:platformclasspath` from `rules_java` 7.6.5. That target depends upon JDK toolchain repos using the previous type, `@bazel_tools//tools/jdk:bootstrap_runtime_toolchain_type`. - No toolchains of that type exist, producing the error. These problems don't appear under Bzlmod, which never needed the `@rules_java_builtin` mechanism. This is because legacy `WORKSPACE` evaluation executes statements sequentially, while Bzlmod builds the module dependency graph _before_ instantiating repositories (within module extensions). In fact, `bazel {build,test} --enable_bzlmod //...` actually works at this point, though the migration hasn't really begun. --- This error happens because `rules_java` up to 7.9.1 contained the following definition in `toolchains/default_java_toolchain.bzl`: ```python _JAVA_BOOTSTRAP_RUNTIME_TOOLCHAIN_TYPE = Label("@bazel_tools//tools/jdk:bootstrap_runtime_toolchain_type") ``` and `rules_java` 7.10.0 changed it to: ```python _JAVA_BOOTSTRAP_RUNTIME_TOOLCHAIN_TYPE = Label("//toolchains:bootstrap_runtime_toolchain_type") ``` - https://github.com/bazelbuild/rules_java/blob/7.9.1/toolchains/default_java_toolchain.bzl#L211 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/default_java_toolchain.bzl#L211 The generated toolchain configuration repos use this same `toolchain_type`, which `rules_java_toolchains()` registers: - https://github.com/bazelbuild/rules_java/blob/7.9.1/toolchains/remote_java_repository.bzl#L92 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/remote_java_repository.bzl#L92 As noted earlier, bazelbuild/rules_java#210 reinstated `_allowlist_function_transition`, required by Bazel 6. However, it also included this `toolchain_type` change. (`rules_java` 7.11.0 later touched up this change for local JDK toolchain repos in:) - bazelbuild/rules_java#215: Fix bootstrap_runtime_toolchain_type reference bazelbuild/rules_java@bcc5062 This affects all toolchains defined using the `default_java_toolchain` macro, which depend upon `@rules_java//toolchains:platformclasspath`. This target, defined by the `bootclasspath` rule, depends upon `_JAVA_BOOTSTRAP_RUNTIME_TOOLCHAIN_TYPE`. - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/default_java_toolchain.bzl#L141 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/default_java_toolchain.bzl#L99 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/default_java_toolchain.bzl#L90 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/BUILD#L254-L258 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/default_java_toolchain.bzl#L304 The `rules_java` setup macro `rules_java_dependencies` depends upon `_remote_jdk_repos_for_version`. This macro wraps each remote toolchain repo instantiation in a `maybe`: - https://github.com/bazelbuild/rules_java/blob/7.6.5/java/repositories.bzl#L331-L341 The `rules_java` setup macros in the legacy `bootcamp/WORKSPACE` file instantiate the 7.10.0 toolchain repos first. This means that nothing happens when the the legacy `WORKSPACE` suffix invokes the 7.6.5 macros. This also means that all the remote JDK toolchain repos have the `toolchain_type` from 7.10.0, not from 7.6.5. `@bazel_tools//tools/jdk:toolchain_jdk_17` is an `alias` to `@rules_java//toolchains:toolchain_jdk_17`. However, Bazel maps this to the `@rules_java_builtin` repo, which is `rules_java` 7.6.5. - https://github.com/bazelbuild/bazel/blob/7.6.2/tools/jdk/BUILD.tools#L177-L178 - https://github.com/bazelbuild/rules_java/blob/7.6.5/toolchains/BUILD#L271-L281 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/BUILD#L271-L281 As a result, that toolchain depends upon the `rules_java` 7.6.5 target, `@rules_java_builtin//toolchains:platformclasspath`. That target depends `@bazel_tools//tools/jdk:bootstrap_runtime_toolchain_type`. Since no existing toolchains have that `toolchain_type`, the build fails. -- `rules_java` 7.12.2 and 8.6.0 actually restored the previous `toolchain_type`; upgrading to either of those versions would also fix this build: - bazelbuild/rules_java#246: bazelbuild/rules_java@b64eb7d bazelbuild/rules_java@4206c53 --- `@bazel_tools/tools/jdk:current_java_toolchain` remains intact. It's an `alias` to `@rules_java//toolchains:current_java_toolchain`, which is a `java_toolchain_alias`. Its `toolchains` attribute contains a direct dependency on `@bazel_tools//tools/jdk:toolchain_type`, which remains the same in `rules_java` 7.10.0. - https://github.com/bazelbuild/bazel/blob/7.6.2/tools/jdk/BUILD.tools#L155 - https://github.com/bazelbuild/rules_java/blob/7.6.5/toolchains/BUILD#L79 - https://github.com/bazelbuild/rules_java/blob/7.6.5/toolchains/java_toolchain_alias.bzl#L104 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/java_toolchain_alias.bzl#L107 --- The "Bump to rules_java 7.9.0 for Bazel 7 compatibility" section of the following commit message describes my first investigation into this phenomenon. It was very close, but not exactly correct, and not as complete as the description above. - bazel-contrib/rules_scala@cd22d88 This has broken other projects in the same way: - bazelbuild/bazel: [Bazel CI] Downstream project broken by rules_java upgrade #23619 bazelbuild/bazel#23619 Bazel 8.0.0 ships with `rules_java` 8.6.1, removed `@rules_java_builtin` from the legacy `WORKSPACE` prefix, and added `@rules_java` to the suffix. - https://github.com/bazelbuild/bazel/blob/8.0.0/MODULE.bazel#L28 - bazelbuild/bazel: Remove rules_java_builtin in WORKSPACE prefix bazelbuild/bazel@7506690
mbland
added a commit
to EngFlow-Academy/bzlmod-bootcamp
that referenced
this pull request
Oct 31, 2025
Resolves the `_allowlist_function_transition` error under Bazel 6, since `rules_java` 7.10.0 adds it back in: - bazelbuild/rules_java#210: Make rules_java backwards compatible with Bazel 6.3.0 bazelbuild/rules_java@30ecf3f However, this version breaks `bootcamp_library` under Bazel 7, which currently uses `@bazel_tools//tools/jdk:toolchain_jdk_17`, with the following error: ```txt $ USE_BAZEL_VERSION=7.6.2 bazel build //... ERROR: external/rules_java_builtin/toolchains/BUILD:254:14: While resolving toolchains for target @@rules_java_builtin//toolchains:platformclasspath (096dcc8): No matching toolchains found for types @@bazel_tools//tools/jdk:bootstrap_runtime_toolchain_type. To debug, rerun with --toolchain_resolution_debug='@@bazel_tools//tools/jdk:bootstrap_runtime_toolchain_type' ``` The next commit fixes this error by replacing that toolchain dependency with `@rules_java//toolchains:toolchain_jdk_17` instead. This is another repo ordering problem related to the legacy `WORKSPACE` prefix from Bazel 7.6.2 instantiating `rules_java` 7.6.5 as `@rules_java_builtin`. - The legacy `WORKSPACE` prefix instantiates `rules_java_builtin` from `rules_java` 7.6.5, as explained in "Bump to Bazel 7.6.2". - Bazel creates a repo mapping from `@rules_java` to `@rules_java_builtin` for `@bazel_tools` in its legacy `WORKSPACE` prefix. https://github.com/bazelbuild/bazel/blob/7.6.2/src/main/java/com/google/devtools/build/lib/bazel/rules/GenericRules.java#L56-L57 https://github.com/bazelbuild/bazel/blob/7.6.2/src/main/java/com/google/devtools/build/lib/bazel/rules/tools.WORKSPACE#L1-L5 - The legacy `bootcamp/WORKSPACE` file instantiates `rules_java` 7.10.0. `rules_java_dependencies` instantiates its JDK toolchain repos using an updated `toolchain_type`, and `rules_java_toolchains` registers them. - The legacy `WORKSPACE` suffix invokes the `rules_java_dependencies` macro from `rules_java` 7.6.5. This does nothing, because `rules_java` wraps the remote JDK toolchain repo rules in a `maybe`, and repos of the same names already exist. - The `@bazel_tools//tools/jdk` toolchains transitively depend upon `@rules_java_builtin//toolchains:platformclasspath` from `rules_java` 7.6.5. That target depends upon JDK toolchain repos using the previous type, `@bazel_tools//tools/jdk:bootstrap_runtime_toolchain_type`. - No toolchains of that type exist, producing the error. These problems don't appear under Bzlmod, which never needed the `@rules_java_builtin` mechanism. This is because legacy `WORKSPACE` evaluation executes statements sequentially, while Bzlmod builds the module dependency graph _before_ instantiating repositories (within module extensions). In fact, `bazel {build,test} --enable_bzlmod //...` actually works at this point, though the migration hasn't really begun. --- This error happens because `rules_java` up to 7.9.1 contained the following definition in `toolchains/default_java_toolchain.bzl`: ```python _JAVA_BOOTSTRAP_RUNTIME_TOOLCHAIN_TYPE = Label("@bazel_tools//tools/jdk:bootstrap_runtime_toolchain_type") ``` and `rules_java` 7.10.0 changed it to: ```python _JAVA_BOOTSTRAP_RUNTIME_TOOLCHAIN_TYPE = Label("//toolchains:bootstrap_runtime_toolchain_type") ``` - https://github.com/bazelbuild/rules_java/blob/7.9.1/toolchains/default_java_toolchain.bzl#L211 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/default_java_toolchain.bzl#L211 The generated toolchain configuration repos use this same `toolchain_type`, which `rules_java_toolchains()` registers: - https://github.com/bazelbuild/rules_java/blob/7.9.1/toolchains/remote_java_repository.bzl#L92 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/remote_java_repository.bzl#L92 As noted earlier, bazelbuild/rules_java#210 reinstated `_allowlist_function_transition`, required by Bazel 6. However, it also included this `toolchain_type` change. (`rules_java` 7.11.0 later touched up this change for local JDK toolchain repos in:) - bazelbuild/rules_java#215: Fix bootstrap_runtime_toolchain_type reference bazelbuild/rules_java@bcc5062 This affects all toolchains defined using the `default_java_toolchain` macro, which depend upon `@rules_java//toolchains:platformclasspath`. This target, defined by the `bootclasspath` rule, depends upon `_JAVA_BOOTSTRAP_RUNTIME_TOOLCHAIN_TYPE`. - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/default_java_toolchain.bzl#L141 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/default_java_toolchain.bzl#L99 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/default_java_toolchain.bzl#L90 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/BUILD#L254-L258 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/default_java_toolchain.bzl#L304 The `rules_java` setup macro `rules_java_dependencies` depends upon `_remote_jdk_repos_for_version`. This macro wraps each remote toolchain repo instantiation in a `maybe`: - https://github.com/bazelbuild/rules_java/blob/7.6.5/java/repositories.bzl#L331-L341 The `rules_java` setup macros in the legacy `bootcamp/WORKSPACE` file instantiate the 7.10.0 toolchain repos first. This means that nothing happens when the the legacy `WORKSPACE` suffix invokes the 7.6.5 macros. This also means that all the remote JDK toolchain repos have the `toolchain_type` from 7.10.0, not from 7.6.5. `@bazel_tools//tools/jdk:toolchain_jdk_17` is an `alias` to `@rules_java//toolchains:toolchain_jdk_17`. However, Bazel maps this to the `@rules_java_builtin` repo, which is `rules_java` 7.6.5. - https://github.com/bazelbuild/bazel/blob/7.6.2/tools/jdk/BUILD.tools#L177-L178 - https://github.com/bazelbuild/rules_java/blob/7.6.5/toolchains/BUILD#L271-L281 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/BUILD#L271-L281 As a result, that toolchain depends upon the `rules_java` 7.6.5 target, `@rules_java_builtin//toolchains:platformclasspath`. That target depends `@bazel_tools//tools/jdk:bootstrap_runtime_toolchain_type`. Since no existing toolchains have that `toolchain_type`, the build fails. -- `rules_java` 7.12.2 and 8.6.0 actually restored the previous `toolchain_type`; upgrading to either of those versions would also fix this build: - bazelbuild/rules_java#246: bazelbuild/rules_java@b64eb7d bazelbuild/rules_java@4206c53 --- `@bazel_tools/tools/jdk:current_java_toolchain` remains intact. It's an `alias` to `@rules_java//toolchains:current_java_toolchain`, which is a `java_toolchain_alias`. Its `toolchains` attribute contains a direct dependency on `@bazel_tools//tools/jdk:toolchain_type`, which remains the same in `rules_java` 7.10.0. - https://github.com/bazelbuild/bazel/blob/7.6.2/tools/jdk/BUILD.tools#L155 - https://github.com/bazelbuild/rules_java/blob/7.6.5/toolchains/BUILD#L79 - https://github.com/bazelbuild/rules_java/blob/7.6.5/toolchains/java_toolchain_alias.bzl#L104 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/java_toolchain_alias.bzl#L107 --- The "Bump to rules_java 7.9.0 for Bazel 7 compatibility" section of the following commit message describes my first investigation into this phenomenon. It was very close, but not exactly correct, and not as complete as the description above. - bazel-contrib/rules_scala@cd22d88 This has broken other projects in the same way: - bazelbuild/bazel: [Bazel CI] Downstream project broken by rules_java upgrade #23619 bazelbuild/bazel#23619 Bazel 8.0.0 ships with `rules_java` 8.6.1, removed `@rules_java_builtin` from the legacy `WORKSPACE` prefix, and added `@rules_java` to the suffix. - https://github.com/bazelbuild/bazel/blob/8.0.0/MODULE.bazel#L28 - bazelbuild/bazel: Remove rules_java_builtin in WORKSPACE prefix bazelbuild/bazel@7506690
mbland
added a commit
to EngFlow-Academy/bzlmod-bootcamp
that referenced
this pull request
Nov 5, 2025
Resolves the `_allowlist_function_transition` error under Bazel 6, since `rules_java` 7.10.0 adds it back in: - bazelbuild/rules_java#210: Make rules_java backwards compatible with Bazel 6.3.0 bazelbuild/rules_java@30ecf3f However, this version breaks `bootcamp_library` under Bazel 7, which currently uses `@bazel_tools//tools/jdk:toolchain_jdk_17`, with the following error: ```txt $ USE_BAZEL_VERSION=7.7.0 bazel build //... ERROR: external/rules_java_builtin/toolchains/BUILD:254:14: While resolving toolchains for target @@rules_java_builtin//toolchains:platformclasspath (096dcc8): No matching toolchains found for types @@bazel_tools//tools/jdk:bootstrap_runtime_toolchain_type. To debug, rerun with --toolchain_resolution_debug='@@bazel_tools//tools/jdk:bootstrap_runtime_toolchain_type' ``` The next commit fixes this error by replacing that toolchain dependency with `@rules_java//toolchains:toolchain_jdk_17` instead. This is another repo ordering problem related to the legacy `WORKSPACE` prefix from Bazel 7.7.0 instantiating `rules_java` 7.6.5 as `@rules_java_builtin`. - The legacy `WORKSPACE` prefix instantiates `rules_java_builtin` from `rules_java` 7.6.5, as explained in "Bump to Bazel 7.7.0". - Bazel creates a repo mapping from `@rules_java` to `@rules_java_builtin` for `@bazel_tools` in its legacy `WORKSPACE` prefix. https://github.com/bazelbuild/bazel/blob/7.7.0/src/main/java/com/google/devtools/build/lib/bazel/rules/GenericRules.java#L56-L57 https://github.com/bazelbuild/bazel/blob/7.7.0/src/main/java/com/google/devtools/build/lib/bazel/rules/tools.WORKSPACE#L1-L5 - The legacy `bootcamp/WORKSPACE` file instantiates `rules_java` 7.10.0. `rules_java_dependencies` instantiates its JDK toolchain repos using an updated `toolchain_type`, and `rules_java_toolchains` registers them. - The legacy `WORKSPACE` suffix invokes the `rules_java_dependencies` macro from `rules_java` 7.6.5. This does nothing, because `rules_java` wraps the remote JDK toolchain repo rules in a `maybe`, and repos of the same names already exist. - The `@bazel_tools//tools/jdk` toolchains transitively depend upon `@rules_java_builtin//toolchains:platformclasspath` from `rules_java` 7.6.5. That target depends upon JDK toolchain repos using the previous type, `@bazel_tools//tools/jdk:bootstrap_runtime_toolchain_type`. - No toolchains of that type exist, producing the error. These problems don't appear under Bzlmod, which never needed the `@rules_java_builtin` mechanism. This is because legacy `WORKSPACE` evaluation executes statements sequentially, while Bzlmod builds the module dependency graph _before_ instantiating repositories (within module extensions). In fact, `bazel {build,test} --enable_bzlmod //...` actually works at this point, though the migration hasn't really begun. --- This error happens because `rules_java` up to 7.9.1 contained the following definition in `toolchains/default_java_toolchain.bzl`: ```python _JAVA_BOOTSTRAP_RUNTIME_TOOLCHAIN_TYPE = Label("@bazel_tools//tools/jdk:bootstrap_runtime_toolchain_type") ``` and `rules_java` 7.10.0 changed it to: ```python _JAVA_BOOTSTRAP_RUNTIME_TOOLCHAIN_TYPE = Label("//toolchains:bootstrap_runtime_toolchain_type") ``` - https://github.com/bazelbuild/rules_java/blob/7.9.1/toolchains/default_java_toolchain.bzl#L211 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/default_java_toolchain.bzl#L211 The generated toolchain configuration repos use this same `toolchain_type`, which `rules_java_toolchains()` registers: - https://github.com/bazelbuild/rules_java/blob/7.9.1/toolchains/remote_java_repository.bzl#L92 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/remote_java_repository.bzl#L92 As noted earlier, bazelbuild/rules_java#210 reinstated `_allowlist_function_transition`, required by Bazel 6. However, it also included this `toolchain_type` change. (`rules_java` 7.11.0 later touched up this change for local JDK toolchain repos in:) - bazelbuild/rules_java#215: Fix bootstrap_runtime_toolchain_type reference bazelbuild/rules_java@bcc5062 This affects all toolchains defined using the `default_java_toolchain` macro, which depend upon `@rules_java//toolchains:platformclasspath`. This target, defined by the `bootclasspath` rule, depends upon `_JAVA_BOOTSTRAP_RUNTIME_TOOLCHAIN_TYPE`. - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/default_java_toolchain.bzl#L141 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/default_java_toolchain.bzl#L99 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/default_java_toolchain.bzl#L90 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/BUILD#L254-L258 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/default_java_toolchain.bzl#L304 The `rules_java` setup macro `rules_java_dependencies` depends upon `_remote_jdk_repos_for_version`. This macro wraps each remote toolchain repo instantiation in a `maybe`: - https://github.com/bazelbuild/rules_java/blob/7.6.5/java/repositories.bzl#L331-L341 The `rules_java` setup macros in the legacy `bootcamp/WORKSPACE` file instantiate the 7.10.0 toolchain repos first. This means that nothing happens when the the legacy `WORKSPACE` suffix invokes the 7.6.5 macros. This also means that all the remote JDK toolchain repos have the `toolchain_type` from 7.10.0, not from 7.6.5. `@bazel_tools//tools/jdk:toolchain_jdk_17` is an `alias` to `@rules_java//toolchains:toolchain_jdk_17`. However, Bazel maps this to the `@rules_java_builtin` repo, which is `rules_java` 7.6.5. - https://github.com/bazelbuild/bazel/blob/7.7.0/tools/jdk/BUILD.tools#L177-L178 - https://github.com/bazelbuild/rules_java/blob/7.6.5/toolchains/BUILD#L271-L281 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/BUILD#L271-L281 As a result, that toolchain depends upon the `rules_java` 7.6.5 target, `@rules_java_builtin//toolchains:platformclasspath`. That target depends `@bazel_tools//tools/jdk:bootstrap_runtime_toolchain_type`. Since no existing toolchains have that `toolchain_type`, the build fails. -- `rules_java` 7.12.2 and 8.6.0 actually restored the previous `toolchain_type`; upgrading to either of those versions would also fix this build: - bazelbuild/rules_java#246: bazelbuild/rules_java@b64eb7d bazelbuild/rules_java@4206c53 --- `@bazel_tools/tools/jdk:current_java_toolchain` remains intact. It's an `alias` to `@rules_java//toolchains:current_java_toolchain`, which is a `java_toolchain_alias`. Its `toolchains` attribute contains a direct dependency on `@bazel_tools//tools/jdk:toolchain_type`, which remains the same in `rules_java` 7.10.0. - https://github.com/bazelbuild/bazel/blob/7.7.0/tools/jdk/BUILD.tools#L155 - https://github.com/bazelbuild/rules_java/blob/7.6.5/toolchains/BUILD#L79 - https://github.com/bazelbuild/rules_java/blob/7.6.5/toolchains/java_toolchain_alias.bzl#L104 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/java_toolchain_alias.bzl#L107 --- The "Bump to rules_java 7.9.0 for Bazel 7 compatibility" section of the following commit message describes my first investigation into this phenomenon. It was very close, but not exactly correct, and not as complete as the description above. - bazel-contrib/rules_scala@cd22d88 This has broken other projects in the same way: - bazelbuild/bazel: [Bazel CI] Downstream project broken by rules_java upgrade #23619 bazelbuild/bazel#23619 Bazel 8.0.0 ships with `rules_java` 8.6.1, removed `@rules_java_builtin` from the legacy `WORKSPACE` prefix, and added `@rules_java` to the suffix. - https://github.com/bazelbuild/bazel/blob/8.0.0/MODULE.bazel#L28 - bazelbuild/bazel: Remove rules_java_builtin in WORKSPACE prefix bazelbuild/bazel@7506690
mbland
added a commit
to EngFlow-Academy/bzlmod-bootcamp
that referenced
this pull request
Nov 7, 2025
Resolves the `_allowlist_function_transition` error under Bazel 6, since `rules_java` 7.10.0 adds it back in: - bazelbuild/rules_java#210: Make rules_java backwards compatible with Bazel 6.3.0 bazelbuild/rules_java@30ecf3f However, this version breaks `bootcamp_library` under Bazel 7, which currently uses `@bazel_tools//tools/jdk:toolchain_jdk_17`, with the following error: ```txt $ USE_BAZEL_VERSION=7.7.0 bazel build //... ERROR: external/rules_java_builtin/toolchains/BUILD:254:14: While resolving toolchains for target @@rules_java_builtin//toolchains:platformclasspath (096dcc8): No matching toolchains found for types @@bazel_tools//tools/jdk:bootstrap_runtime_toolchain_type. To debug, rerun with --toolchain_resolution_debug='@@bazel_tools//tools/jdk:bootstrap_runtime_toolchain_type' ``` The next commit fixes this error by replacing that toolchain dependency with `@rules_java//toolchains:toolchain_jdk_17` instead. This is another repo ordering problem related to the legacy `WORKSPACE` prefix from Bazel 7.7.0 instantiating `rules_java` 7.6.5 as `@rules_java_builtin`. - The legacy `WORKSPACE` prefix instantiates `rules_java_builtin` from `rules_java` 7.6.5, as explained in "Bump to Bazel 7.7.0". - Bazel creates a repo mapping from `@rules_java` to `@rules_java_builtin` for `@bazel_tools` in its legacy `WORKSPACE` prefix. https://github.com/bazelbuild/bazel/blob/7.7.0/src/main/java/com/google/devtools/build/lib/bazel/rules/GenericRules.java#L56-L57 https://github.com/bazelbuild/bazel/blob/7.7.0/src/main/java/com/google/devtools/build/lib/bazel/rules/tools.WORKSPACE#L1-L5 - The legacy `bootcamp/WORKSPACE` file instantiates `rules_java` 7.10.0. `rules_java_dependencies` instantiates its JDK toolchain repos using an updated `toolchain_type`, and `rules_java_toolchains` registers them. - The legacy `WORKSPACE` suffix invokes the `rules_java_dependencies` macro from `rules_java` 7.6.5. This does nothing, because `rules_java` wraps the remote JDK toolchain repo rules in a `maybe`, and repos of the same names already exist. - The `@bazel_tools//tools/jdk` toolchains transitively depend upon `@rules_java_builtin//toolchains:platformclasspath` from `rules_java` 7.6.5. That target depends upon JDK toolchain repos using the previous type, `@bazel_tools//tools/jdk:bootstrap_runtime_toolchain_type`. - No toolchains of that type exist, producing the error. These problems don't appear under Bzlmod, which never needed the `@rules_java_builtin` mechanism. This is because legacy `WORKSPACE` evaluation executes statements sequentially, while Bzlmod builds the module dependency graph _before_ instantiating repositories (within module extensions). In fact, `bazel {build,test} --enable_bzlmod //...` actually works at this point, though the migration hasn't really begun. --- This error happens because `rules_java` up to 7.9.1 contained the following definition in `toolchains/default_java_toolchain.bzl`: ```python _JAVA_BOOTSTRAP_RUNTIME_TOOLCHAIN_TYPE = Label("@bazel_tools//tools/jdk:bootstrap_runtime_toolchain_type") ``` and `rules_java` 7.10.0 changed it to: ```python _JAVA_BOOTSTRAP_RUNTIME_TOOLCHAIN_TYPE = Label("//toolchains:bootstrap_runtime_toolchain_type") ``` - https://github.com/bazelbuild/rules_java/blob/7.9.1/toolchains/default_java_toolchain.bzl#L211 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/default_java_toolchain.bzl#L211 The generated toolchain configuration repos use this same `toolchain_type`, which `rules_java_toolchains()` registers: - https://github.com/bazelbuild/rules_java/blob/7.9.1/toolchains/remote_java_repository.bzl#L92 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/remote_java_repository.bzl#L92 As noted earlier, bazelbuild/rules_java#210 reinstated `_allowlist_function_transition`, required by Bazel 6. However, it also included this `toolchain_type` change. (`rules_java` 7.11.0 later touched up this change for local JDK toolchain repos in:) - bazelbuild/rules_java#215: Fix bootstrap_runtime_toolchain_type reference bazelbuild/rules_java@bcc5062 This affects all toolchains defined using the `default_java_toolchain` macro, which depend upon `@rules_java//toolchains:platformclasspath`. This target, defined by the `bootclasspath` rule, depends upon `_JAVA_BOOTSTRAP_RUNTIME_TOOLCHAIN_TYPE`. - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/default_java_toolchain.bzl#L141 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/default_java_toolchain.bzl#L99 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/default_java_toolchain.bzl#L90 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/BUILD#L254-L258 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/default_java_toolchain.bzl#L304 The `rules_java` setup macro `rules_java_dependencies` depends upon `_remote_jdk_repos_for_version`. This macro wraps each remote toolchain repo instantiation in a `maybe`: - https://github.com/bazelbuild/rules_java/blob/7.6.5/java/repositories.bzl#L331-L341 The `rules_java` setup macros in the legacy `bootcamp/WORKSPACE` file instantiate the 7.10.0 toolchain repos first. This means that nothing happens when the the legacy `WORKSPACE` suffix invokes the 7.6.5 macros. This also means that all the remote JDK toolchain repos have the `toolchain_type` from 7.10.0, not from 7.6.5. `@bazel_tools//tools/jdk:toolchain_jdk_17` is an `alias` to `@rules_java//toolchains:toolchain_jdk_17`. However, Bazel maps this to the `@rules_java_builtin` repo, which is `rules_java` 7.6.5. - https://github.com/bazelbuild/bazel/blob/7.7.0/tools/jdk/BUILD.tools#L177-L178 - https://github.com/bazelbuild/rules_java/blob/7.6.5/toolchains/BUILD#L271-L281 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/BUILD#L271-L281 As a result, that toolchain depends upon the `rules_java` 7.6.5 target, `@rules_java_builtin//toolchains:platformclasspath`. That target depends `@bazel_tools//tools/jdk:bootstrap_runtime_toolchain_type`. Since no existing toolchains have that `toolchain_type`, the build fails. -- `rules_java` 7.12.2 and 8.6.0 actually restored the previous `toolchain_type`; upgrading to either of those versions would also fix this build: - bazelbuild/rules_java#246: bazelbuild/rules_java@b64eb7d bazelbuild/rules_java@4206c53 --- `@bazel_tools/tools/jdk:current_java_toolchain` remains intact. It's an `alias` to `@rules_java//toolchains:current_java_toolchain`, which is a `java_toolchain_alias`. Its `toolchains` attribute contains a direct dependency on `@bazel_tools//tools/jdk:toolchain_type`, which remains the same in `rules_java` 7.10.0. - https://github.com/bazelbuild/bazel/blob/7.7.0/tools/jdk/BUILD.tools#L155 - https://github.com/bazelbuild/rules_java/blob/7.6.5/toolchains/BUILD#L79 - https://github.com/bazelbuild/rules_java/blob/7.6.5/toolchains/java_toolchain_alias.bzl#L104 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/java_toolchain_alias.bzl#L107 --- The "Bump to rules_java 7.9.0 for Bazel 7 compatibility" section of the following commit message describes my first investigation into this phenomenon. It was very close, but not exactly correct, and not as complete as the description above. - bazel-contrib/rules_scala@cd22d88 This has broken other projects in the same way: - bazelbuild/bazel: [Bazel CI] Downstream project broken by rules_java upgrade #23619 bazelbuild/bazel#23619 Bazel 8.0.0 ships with `rules_java` 8.6.1, removed `@rules_java_builtin` from the legacy `WORKSPACE` prefix, and added `@rules_java` to the suffix. - https://github.com/bazelbuild/bazel/blob/8.0.0/MODULE.bazel#L28 - bazelbuild/bazel: Remove rules_java_builtin in WORKSPACE prefix bazelbuild/bazel@7506690
mbland
added a commit
to EngFlow-Academy/bzlmod-bootcamp
that referenced
this pull request
Nov 7, 2025
Resolves the `_allowlist_function_transition` error under Bazel 6, since `rules_java` 7.10.0 adds it back in: - bazelbuild/rules_java#210: Make rules_java backwards compatible with Bazel 6.3.0 bazelbuild/rules_java@30ecf3f However, this version breaks `bootcamp_library` under Bazel 7, which currently uses `@bazel_tools//tools/jdk:toolchain_jdk_17`, with the following error: ```txt $ USE_BAZEL_VERSION=7.7.0 bazel build //... ERROR: external/rules_java_builtin/toolchains/BUILD:254:14: While resolving toolchains for target @@rules_java_builtin//toolchains:platformclasspath (096dcc8): No matching toolchains found for types @@bazel_tools//tools/jdk:bootstrap_runtime_toolchain_type. To debug, rerun with --toolchain_resolution_debug='@@bazel_tools//tools/jdk:bootstrap_runtime_toolchain_type' ``` The next commit fixes this error by replacing that toolchain dependency with `@rules_java//toolchains:toolchain_jdk_17` instead. This is another repo ordering problem related to the legacy `WORKSPACE` prefix from Bazel 7.7.0 instantiating `rules_java` 7.6.5 as `@rules_java_builtin`. - The legacy `WORKSPACE` prefix instantiates `rules_java_builtin` from `rules_java` 7.6.5, as explained in "Bump to Bazel 7.7.0". - Bazel creates a repo mapping from `@rules_java` to `@rules_java_builtin` for `@bazel_tools` in its legacy `WORKSPACE` prefix. https://github.com/bazelbuild/bazel/blob/7.7.0/src/main/java/com/google/devtools/build/lib/bazel/rules/GenericRules.java#L56-L57 https://github.com/bazelbuild/bazel/blob/7.7.0/src/main/java/com/google/devtools/build/lib/bazel/rules/tools.WORKSPACE#L1-L5 - The legacy `bootcamp/WORKSPACE` file instantiates `rules_java` 7.10.0. `rules_java_dependencies` instantiates its JDK toolchain repos using an updated `toolchain_type`, and `rules_java_toolchains` registers them. - The legacy `WORKSPACE` suffix invokes the `rules_java_dependencies` macro from `rules_java` 7.6.5. This does nothing, because `rules_java` wraps the remote JDK toolchain repo rules in a `maybe`, and repos of the same names already exist. - The `@bazel_tools//tools/jdk` toolchains transitively depend upon `@rules_java_builtin//toolchains:platformclasspath` from `rules_java` 7.6.5. That target depends upon JDK toolchain repos using the previous type, `@bazel_tools//tools/jdk:bootstrap_runtime_toolchain_type`. - No toolchains of that type exist, producing the error. These problems don't appear under Bzlmod, which never needed the `@rules_java_builtin` mechanism. This is because legacy `WORKSPACE` evaluation executes statements sequentially, while Bzlmod builds the module dependency graph _before_ instantiating repositories (within module extensions). In fact, `bazel {build,test} --enable_bzlmod //...` actually works at this point, though the migration hasn't really begun. --- This error happens because `rules_java` up to 7.9.1 contained the following definition in `toolchains/default_java_toolchain.bzl`: ```python _JAVA_BOOTSTRAP_RUNTIME_TOOLCHAIN_TYPE = Label("@bazel_tools//tools/jdk:bootstrap_runtime_toolchain_type") ``` and `rules_java` 7.10.0 changed it to: ```python _JAVA_BOOTSTRAP_RUNTIME_TOOLCHAIN_TYPE = Label("//toolchains:bootstrap_runtime_toolchain_type") ``` - https://github.com/bazelbuild/rules_java/blob/7.9.1/toolchains/default_java_toolchain.bzl#L211 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/default_java_toolchain.bzl#L211 The generated toolchain configuration repos use this same `toolchain_type`, which `rules_java_toolchains()` registers: - https://github.com/bazelbuild/rules_java/blob/7.9.1/toolchains/remote_java_repository.bzl#L92 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/remote_java_repository.bzl#L92 As noted earlier, bazelbuild/rules_java#210 reinstated `_allowlist_function_transition`, required by Bazel 6. However, it also included this `toolchain_type` change. (`rules_java` 7.11.0 later touched up this change for local JDK toolchain repos in:) - bazelbuild/rules_java#215: Fix bootstrap_runtime_toolchain_type reference bazelbuild/rules_java@bcc5062 This affects all toolchains defined using the `default_java_toolchain` macro, which depend upon `@rules_java//toolchains:platformclasspath`. This target, defined by the `bootclasspath` rule, depends upon `_JAVA_BOOTSTRAP_RUNTIME_TOOLCHAIN_TYPE`. - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/default_java_toolchain.bzl#L141 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/default_java_toolchain.bzl#L99 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/default_java_toolchain.bzl#L90 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/BUILD#L254-L258 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/default_java_toolchain.bzl#L304 The `rules_java` setup macro `rules_java_dependencies` depends upon `_remote_jdk_repos_for_version`. This macro wraps each remote toolchain repo instantiation in a `maybe`: - https://github.com/bazelbuild/rules_java/blob/7.6.5/java/repositories.bzl#L331-L341 The `rules_java` setup macros in the legacy `bootcamp/WORKSPACE` file instantiate the 7.10.0 toolchain repos first. This means that nothing happens when the the legacy `WORKSPACE` suffix invokes the 7.6.5 macros. This also means that all the remote JDK toolchain repos have the `toolchain_type` from 7.10.0, not from 7.6.5. `@bazel_tools//tools/jdk:toolchain_jdk_17` is an `alias` to `@rules_java//toolchains:toolchain_jdk_17`. However, Bazel maps this to the `@rules_java_builtin` repo, which is `rules_java` 7.6.5. - https://github.com/bazelbuild/bazel/blob/7.7.0/tools/jdk/BUILD.tools#L177-L178 - https://github.com/bazelbuild/rules_java/blob/7.6.5/toolchains/BUILD#L271-L281 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/BUILD#L271-L281 As a result, that toolchain depends upon the `rules_java` 7.6.5 target, `@rules_java_builtin//toolchains:platformclasspath`. That target depends `@bazel_tools//tools/jdk:bootstrap_runtime_toolchain_type`. Since no existing toolchains have that `toolchain_type`, the build fails. -- `rules_java` 7.12.2 and 8.6.0 actually restored the previous `toolchain_type`; upgrading to either of those versions would also fix this build: - bazelbuild/rules_java#246: bazelbuild/rules_java@b64eb7d bazelbuild/rules_java@4206c53 --- `@bazel_tools/tools/jdk:current_java_toolchain` remains intact. It's an `alias` to `@rules_java//toolchains:current_java_toolchain`, which is a `java_toolchain_alias`. Its `toolchains` attribute contains a direct dependency on `@bazel_tools//tools/jdk:toolchain_type`, which remains the same in `rules_java` 7.10.0. - https://github.com/bazelbuild/bazel/blob/7.7.0/tools/jdk/BUILD.tools#L155 - https://github.com/bazelbuild/rules_java/blob/7.6.5/toolchains/BUILD#L79 - https://github.com/bazelbuild/rules_java/blob/7.6.5/toolchains/java_toolchain_alias.bzl#L104 - https://github.com/bazelbuild/rules_java/blob/7.10.0/toolchains/java_toolchain_alias.bzl#L107 --- The "Bump to rules_java 7.9.0 for Bazel 7 compatibility" section of the following commit message describes my first investigation into this phenomenon. It was very close, but not exactly correct, and not as complete as the description above. - bazel-contrib/rules_scala@cd22d88 This has broken other projects in the same way: - bazelbuild/bazel: [Bazel CI] Downstream project broken by rules_java upgrade #23619 bazelbuild/bazel#23619 Bazel 8.0.0 ships with `rules_java` 8.6.1, removed `@rules_java_builtin` from the legacy `WORKSPACE` prefix, and added `@rules_java` to the suffix. - https://github.com/bazelbuild/bazel/blob/8.0.0/MODULE.bazel#L28 - bazelbuild/bazel: Remove rules_java_builtin in WORKSPACE prefix bazelbuild/bazel@7506690
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
No description provided.