Run rules_jvm_external jar tools with exec Java

[dzbarsky]

Summary

• patch rules_jvm_external 6.8 so jvm_import runs AddJarManifestEntry_deploy.jar with current_java_runtime in the exec configuration
• use local_jdk for bootstrap Java runtimes so the offline source distribution build does not fetch remote JDK 21 archives
• update MODULE.bazel.lock

Motivation

This replaces #29764, which was erased from master after an accidental GitHub merge. Invoking the deploy JAR through current_java_runtime avoids executing the generated Bash launcher on a Windows host with Linux remote execution. The new runtime dependency made //src/test/shell/bazel:bazel_bootstrap_distfile_test resolve remotejdk21_*, which is intentionally absent from the offline distribution repository cache; the bootstrap already requires JAVA_HOME, so selecting local_jdk keeps the bootstrap offline while retaining Java language level 21.

The corresponding upstream change is bazel-contrib/rules_jvm_external#1583.

Validation

• bazel test //src/test/shell/bazel:bazel_bootstrap_distfile_test with JDK 21 (passed in 1671.2s)
• bazel mod deps --lockfile_mode=error
• bash -n scripts/bootstrap/bootstrap.sh

[dzbarsky]

@Wyverald @fmeum PTAL - resending this since it got deleted, confirmed manual bootstrap test passes

[fmeum]

This looks good to me, but I would like to understand better why the changes result in the bootstrap build fetching a remotejdk when it previously didn't. Could you explain this in more detail in the PR description?

[hvadehra]

This should already be the case. Do you know what's going wrong?

[dzbarsky]

JAVA_HOME already supplies the JDK used by scripts/bootstrap/BUILD.bootstrap, but the new @rules_java//toolchains:current_java_runtime dependency performs separate Java runtime toolchain resolution. The existing --java_runtime_version=21 and --tool_java_runtime_version=21 select local_jdk only when JAVA_HOME contains JDK 21. The bootstrap accepts any JDK >= 21, so with JDK 25 I reproduced toolchain resolution rejecting @@rules_java++toolchains+local_jdk//:runtime_toolchain_definition because its detected version is 25 and selecting @@rules_java++toolchains+remotejdk21_macos_aarch64//:jdk instead. That repository is intentionally absent from the offline bootstrap repository cache, so the nested bootstrap tries to download it and fails.

Selecting local_jdk by name makes both runtime selectors use JAVA_HOME regardless of its newer major version. The Java language selectors remain 21, and scripts/bootstrap/compile.sh checks that JAVA_HOME is at least that version. I also verified the inverse toolchain result: with both runtime selectors set to local_jdk, the JDK 25 run selects @@rules_java++toolchains+local_jdk//:jdk.

-zbarskybot

[hvadehra]

This reasoning does not sound right to me. I'll look further into this and report back.

[fmeum]

#30106 also runs into similar issues. It would be great to have more direct (in particular, early) checks for the expected host-provided dependencies of the bootstrap build.

[hvadehra]

Can you try running //src/test/shell/bazel:bazel_determinism_test on this as well?

[hvadehra]

This reasoning does not sound right to me. I'll look further into this and report back.

[dzbarsky]

Confirmed at 3e7556408ff2d078996a2141c6d09eab188e5c08: //src/test/shell/bazel:bazel_determinism_test passes on macOS arm64 with JDK 21 (PASSED in 1926.8s). The two Bazel builds produced identical output hashes.

I ran the test action locally and disabled the test harness's forced IPv6 preference because this host advertises an IPv6 default route but cannot reach bcr.bazel.build over it; the initial attempts failed during registry fetches before either build. No PR change is needed.

-zbarskybot