Fix last_green w/bazel_worker_api rules_java 8.15

[mbland]

Description

Uses the bazel_worker_java module 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 from commit 00b48b27aa216befc419e540919a1f1df4cda337.

Note, though, that this change bumps rules_java to 8.15.0, since it's now available. This change also updates:

• gazelle: 0.44.0 => 0.45.0
• rules_go: 0.55.1 => 0.56.1
• rules_shell: 0.5.0 => 0.5.1

It also updates these Maven artifact versions:

• Scalafmt: 3.9.8 => 3.9.9
• grpc: 1.73.0 => 1.74.0
• proto-google-common-protos: 2.59.2 => 2.60.0
• sbt-util-interface: 1.11.3 => 1.11.4

Also:

• Removes the --incompatible_autoload_externally flag from .bazelrc.

• Removes the Bazel 9.0.0-pre.20250710.1 CI job added by Bump dependency versions for rules_scala v7.1.0 #1755, since it's no longer necessary given the fix from this change.

• 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)

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 creates @bazel_worker_{api,java} repos from the bazel-worker-api archive using @Wyverald's http_archive and strip_prefix suggestion from #1756.

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.

[simuons]

Hi, @mbland as always thanks for the PR. Sorry it got conflicts. Could you rebase it. And then I'll merge.

[mbland]

@simuons Done, thanks. I also bumped a few more Bazel and Maven dependencies while I was at it. Confirmed that all tests pass locally with WORKSPACE, too.

I also removed the CI job for Bazel 9.0.0-pre.20250710.1 (which landed in #1755), since this pull request fixes the last_green job, rendering it unnecessary.

If you'd prefer I extract the non-rules_java version bumps into a separate PR, I can do that instead. But if you're good with keeping those updates in this PR, I think we'll be OK to release v7.1.0 once it lands (unless there's another reason to wait).

[simuons]

Thanks, @mbland