[Regression] Bazel 8.5.0: java_binary with deploy_env fails: cannot access the _transitive_validation private API

[davido]

Description:

After upgrading from Bazel 7.7.1 to 8.5.0, java_binary targets that utilise the deploy_env attribute fail during the analysis phase. This appears to be a regression related to the Starlarkification of Java rules in Bazel 8.

Error:

@@rules_java+//java/bazel/rules:bazel_java_binary.bzl cannot access the _transitive_validation private API

Environment:

• Bazel: 8.5.0
• rules_java: 9.3.0 (same behaviour in 8.16.1)
• OS: Linux (Ubuntu/Debian via Bazelisk)
• Bzlmod: Enabled

To Reproduce:

To reproduce the analysis failure in a real-world project (Gerrit Code Review):

1. Clone Gerrit recursively:

git clone --recursive https://gerrit.googlesource.com/gerrit
cd gerrit

2. Apply the reproduction change (Change 539509)
3. Bump Bazel version: Update .bazelversion to 8.5.0.
4. Run the build command:

bazelisk build //java/com/google/gerrit/acceptance:framework

Minimal code example:

The error occurs when a java_binary uses another java_binary in its deploy_env attribute.

If deploy_env is removed, the error disappears.

java_binary(
    name = "framework",
    testonly = True,
    deploy_env = [":framework-deploy-env"],
    main_class = "Dummy",
    runtime_deps = [":framework-lib"],
)

java_binary(
    name = "framework-deploy-env",
    testonly = True,
    main_class = "Dummy",
    runtime_deps = ["//some/other:lib"],
)

Impact:

If deploy_env is removed as a workaround, the build succeeds, but the resulting _deploy.jar is significantly larger (~96 MiB vs ~22 MiB in the Gerrit project), which is unsustainable for our workflow (4.3x size increase).

Context / Reference:

• Source: Gerrit Acceptance BUILD
• Workaround applied in Gerrit: Change 539507