Skip to content

Conversation

@comius
Copy link
Collaborator

@comius comius commented Sep 4, 2024

No description provided.

@comius comius requested a review from a team as a code owner September 4, 2024 12:09
@comius comius requested a review from hvadehra September 4, 2024 12:10
@copybara-service copybara-service bot closed this in bcc5062 Sep 4, 2024
@comius comius mentioned this pull request Sep 5, 2024
@hvadehra hvadehra deleted the comius-patch-1 branch September 23, 2024 08:12
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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants