Fix last_green w/bazel_worker_api, rules_java 8.14

[mbland]

Description

Uses the bazel_worker_{api,java} modules and a legacy WORKSPACE shim to replace @bazel_tools//src/main/protobuf:worker_protocol_java_proto. This, and bumping rules_java to 8.14.0, fixes breakages in the latest last_green Bazel at commit 00b48b27aa216befc419e540919a1f1df4cda337.

Also:

• Removes the --incompatible_autoload_externally flag from .bazelrc.

• Fixes _get_compiler_srcjar to return empty compiler_srcjar_objects instead of returning a valid object. test_compiler_srcjar_error 2.12.11 from dt_patches/dt_patch_test.sh caught this under WORKSPACE. Added test_fail_if_compiler_srcjar_object_is_empty to test/shell/test_compiler_sources_integrity.sh to catch the specific problem sooner.

• Fixed regex in target_file_location from test_helper.sh to work with Bazel 6.5.0, and fixed unbound variable in fail message.

• Added logic to teardown_suite in test_bzlmod_macros.sh to avoid unbound variable breakage when running under Bazel 6.5.0.

• Added logic to skip test_check_module_bazel_template under Bazel 6 in test_version.sh.

• Removed restriction to use protobuf v29 or lower with Bazel 6 from README.md.

• Added scala_compiler_source.* to the regular expressions for "canonical reproducible" messages in dt_patches/dt_patch_test.sh. This resolved a test breakage when rules_python began to emit a "canonical reproducible" message. (Also changed --expunge to --expunge_async.)

Motivation

bazelbuild/bazel#26477, which also landed in the 9.0.0-pre.20250714.1 rolling release, broke the last_green build:

$ USE_BAZEL_VERSION=9.0.0-pre.20250714.1 bazel test //src/... //test/...

ERROR: error loading package '@@bazel_tools//src/main/protobuf':
  Unable to find package for
  @@[unknown repo 'grpc-java' requested from @@bazel_tools]//:java_grpc_library.bzl:

  The repository '@@[unknown repo 'grpc-java' requested from @@bazel_tools]'
  could not be resolved:
  No repository visible as '@grpc-java' from repository '@@bazel_tools'.

The failing target, and several others, depended upon @bazel_tools//src/main/protobuf:worker_protocol_java_proto. Nothing else depends on any other target from that package. So upon @Wyverald's advice, I attempted to use the bazel_worker_java module to replace this specific dependency:

• depending on @bazel_tools//src/main/protobuf:deps_java_proto fails in nightly 9.0.0-pre.20250714.1 bazelbuild/bazel#26579 (comment)

Using just bazel_worker_java 0.0.5 at first produced this breakage:

$ USE_BAZEL_VERSION=last_green bazel build //src/... //test/...

ERROR: .../external/bazel_worker_api+/BUILD.bazel:3:1:
  name 'proto_library' is not defined

This is because that version of bazel_worker_java still depends upon bazel_worker_api 0.0.1, which didn't load proto_library from @com_google_protobuf. Adding bazel_worker_api 0.0.5 directly to MODULE.bazel fixed this.

The next failure was due to rules_scala overriding rules_java to be 8.12.0, whereas last_green now requires 8.14.0:

$ USE_BAZEL_VERSION=last_green bazel build //src/... //test/...

ERROR: src/java/io/bazel/rulesscala/jar/BUILD:3:13:
  in java_library rule //src/java/io/bazel/rulesscala/jar:jar:
  Traceback (most recent call last):
    File ".../external/rules_java+/java/bazel/rules/bazel_java_library.bzl",
      line 26, column 35, in _proxy
        return bazel_java_library_rule(
    File ".../external/rules_java+/java/common/rules/impl/bazel_java_library_impl.bzl",
      line 68, column 43, in bazel_java_library_rule
        target, base_info = basic_java_library(
    File ".../external/rules_java+/java/common/rules/impl/basic_java_library_impl.bzl",
      line 127, column 49, in basic_java_library
        java_info, compilation_info = compile_action(
    File ".../external/rules_java+/java/common/rules/impl/compile_action.bzl",
      line 139, column 46, in compile_action
        java_info = _compile_private_for_builtins(
    File ".../external/rules_java+/java/private/java_common_internal.bzl",
      line 217, column 68, in compile
        get_internal_java_common().create_header_compilation_action(

Error in create_header_compilation_action:
  create_header_compilation_action() missing 2 required positional
  arguments: header_compilation_jar, header_compilation_direct_deps

ERROR: src/java/io/bazel/rulesscala/jar/BUILD:3:13:
  Analysis of target '//src/java/io/bazel/rulesscala/jar:jar' failed

Bumping rules_java to 8.14.0 in the single_version_override fixed that.

Finally, since there's no legacy WORKSPACE API in bazelbuild/bazel-worker-api, I had to roll my own new workspace_compat() macro. This macro instantiates @bazel_worker_{api,java} repos from bazelbuild/bazel-worker-api by stripping the prefixes for each module.

Regarding --incompatible_autoload_externally, I'd added it in #1748 when fixing problems with WORKSPACE builds under Bazel 8.2.1. However, it's not really necessary, so I removed it.

[mbland]

@simuons @liucijus I've included some small changes from #1755 in this pull request, including the rules_java 8.14.0 bump and _get_compiler_srcjar fix. You can merge either pull request first; I'll update the other accordingly. Preferably both should land before releasing v7.1.0, especially in light of this pull request. But technically, only #1755 is really required to do so.

Also, now that we no longer depend on @bazel_tools//src/main/protobuf, Bazel 6.5.0 users aren't capped at protobuf v29 anymore. Between that and a couple of small test fixes, all tests pass under Bazel 6.5.0 in legacy WORKSPACE mode still.

I tested this under the legacy WORKSPACE mode using Bazel 6.5.0, 7.6.1, and 8.3.1. I tested this under Bzlmod in Bazel 7.3.1, 8.3.1, rolling (9.0.0-pre.20250716.1) and last_green (00b48b27aa216befc419e540919a1f1df4cda337).

BTW, the last_green CI job for this pull request has passed.

---

@Wyverald Thanks for the tip in bazelbuild/bazel#26579 (comment) for bazelbuild/bazel-worker-api and the bazel_worker_java module. A couple of notes:

• bazel_worker_java still depends on version 0.0.1 of bazel_worker_api. This causes a breakage since it doesn't have Add loads for java_proto_library and proto_library bazelbuild/bazel-worker-api#5 (which landed in 0.0.3). I worked around this by depending on bazel_worker_api 0.0.5 explicitly, but it would be nice for the version in bazel_worker_java to stay in sync.

• Since bazel-worker-api doesn't have a legacy WORKSPACE API, I had to roll my own workspace_compat macro to generate @bazel_worker_api and @bazel_rules_java repos. Is this something that you'd like me to try to contribute to the bazel-worker-api repo? (Note that we're not using @bazel_worker_api//java/src/main/java/com/google/devtools/build/lib/worker:work_request_handlers, so we're sidestepping the rules_jvm_external dependencies.)

[Wyverald]

optional: instead of using _alias_repo, you could just specify this http_archive twice, once with name bazel_worker_api and strip_prefix bazel-worker-api-0.0.5/proto, and once with name bazel_worker_java and strip_prefix bazel-worker-api-0.0.5/java. That's how it works in Bzlmod anyway.

[mbland]

That's much better, thanks! Done in 43addd6.

[Wyverald]

Thanks! I just pushed bazel_worker_{api,java} 0.0.6 to fix the dependency problem.

As for WORKSPACE, since the solution you have is a partial fix anyway, I think we should just let it be. Not sure the full fix is worth it at this point.

[mbland]

Thanks for the bazel_worker_{api,java} 0.0.6 update! I bumped bazel_worker_java to 0.0.6 and dropped bazel_worker_api from MODULE.bazel in 43addd6.