[build] silence protobuf sun.misc.Unsafe warnings from Java compile workers

[titusfortner]

🔗 Related Issues

When #17598 bumped the build from JDK 21 to JDK 25, sun.misc.Unsafe access became a terminal-deprecation warning, so
we're seeing thousands of sun.misc.Unsafe warnings the Java compile workers spam into the console:

WARNING: A terminally deprecated method in sun.misc.Unsafe has been called
WARNING: sun.misc.Unsafe::arrayBaseOffset has been called by com.google.protobuf.UnsafeUtil$MemoryAccessor (file:.../JavaBuilder_deploy.jar)
WARNING: Please consider reporting this to the maintainers of class com.google.protobuf.UnsafeUtil$MemoryAccessor

💥 What does this PR do?

Registers a custom default_java_toolchain that appends --sun-misc-unsafe-memory-access=allow to the worker JVMs (jvm_opts for JavaBuilder, turbine_jvm_opts for Turbine), wired into the base build config so it applies to every build. The warnings are not RBE-specific — the same remotejdk_25 worker emits them on local builds too.

🔧 Implementation Notes

• The warning is JDK 24+ behavior: the old --add-opens workaround rules_java already ships no longer suppresses it; the new --sun-misc-unsafe-memory-access=allow flag does. rules_java runs all its compile workers on remotejdk_25, so the JDK-25 worker emits it.
• A plain bazelrc flag can't reach these workers — --jvmopt/--test_jvmopt/--host_jvm_args all target the wrong process (see JavaBuilder Worker JVM does not use jvm flags specified with --jvmopt bazelbuild/bazel#16486). The only supported lever for worker JVM args is a default_java_toolchain, so this defines one that mirrors rules_java's default config and appends the flag.
• The toolchain is registered without a java_language_version target_setting, so it is selected regardless of which version --java_language_version is pinned to. A BUILD file can't read that bazelrc flag, so pinning a literal version would silently stop matching (and the warnings would return) the day the JDK is bumped. Actual source/target is governed by the global --javacopt="--release 11", so being version-independent is safe.
• Registered in the base build config (not just build:rbe), because the warnings appear on local builds as well — anything compiling Java on the remotejdk_25 worker hits them, not only RBE/CI.

Alternatives Considered

• Filtering the output in ci-build.sh: lighter and would also catch the ClosureWorker and Ruby-bundler lines, but hides symptoms rather than fixing the cause and risks masking future real warnings.
• Waiting for upstream: rules_java#348 was closed "not planned", so no fix is coming from there.

🤖 AI assistance

• AI assisted (complete below)
  • Tool(s): Claude Code
  • What was generated: the toolchain definition, the bazelrc wiring, and this description
  • I reviewed all AI output and can explain the change

💡 Additional Considerations

• There are other warnings spamming console output not covered by this

🔄 Types of changes

• Cleanup (formatting, renaming)

[qodo-code-review]

Review Summary by Qodo

Silence protobuf sun.misc.Unsafe warnings from Java compile workers

🐞 Bug fix ✨ Enhancement

Walkthroughs

Description

• Suppress protobuf sun.misc.Unsafe warnings from JDK 25 compile workers
• Add custom Java toolchain with --sun-misc-unsafe-memory-access=allow flag
• Register toolchain in base build config for local and RBE builds
• Version-independent toolchain selection across JDK updates

Diagram

flowchart LR
  A["JDK 25 Compile Workers"] -->|emit warnings| B["sun.misc.Unsafe Deprecation"]
  C["Custom Java Toolchain"] -->|adds flag| D["--sun-misc-unsafe-memory-access=allow"]
  D -->|suppresses| B
  E[".bazelrc"] -->|registers| C
  C -->|applies to| F["Local & RBE Builds"]

Loading

File Changes

1. .bazelrc ⚙️ Configuration changes +3/-0

Register custom Java toolchain in bazelrc

• Added comment explaining the purpose of the toolchain registration
• Registered custom Java toolchain via --extra_toolchains flag
• Wired into base build config to apply universally

.bazelrc

---

2. common/remote-build/java/BUILD.bazel ✨ Enhancement +23/-0

Create custom Java toolchain to suppress unsafe warnings

• Created new file with custom default_java_toolchain definition
• Extended DEFAULT_TOOLCHAIN_CONFIGURATION with --sun-misc-unsafe-memory-access=allow flag
• Added flag to both jvm_opts and turbine_jvm_opts for compile workers
• Defined toolchain without java_language_version for version-independent selection

common/remote-build/java/BUILD.bazel

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0)

1. Pinned JDK in toolchain 🐞 Bug ⚙ Maintainability

Description

//common/remote-build/java:java-toolchain hard-codes java_runtime to
@rules_java//toolchains:remotejdk_25, so future JDK bumps can silently keep compile workers on 25
(or fail if that label stops existing). This contradicts the comment claiming it will “stay selected
across JDK bumps” and makes upgrades require synchronized edits in multiple places.

Code

common/remote-build/java/BUILD.bazel[R10-14]

+    configuration = DEFAULT_TOOLCHAIN_CONFIGURATION | {
+        "java_runtime": "@rules_java//toolchains:remotejdk_25",
+        "jvm_opts": DEFAULT_TOOLCHAIN_CONFIGURATION["jvm_opts"] + _SILENCE_UNSAFE_WARNING,
+        "turbine_jvm_opts": DEFAULT_TOOLCHAIN_CONFIGURATION["turbine_jvm_opts"] + _SILENCE_UNSAFE_WARNING,
+    },

Evidence

The toolchain file explicitly pins java_runtime to remotejdk_25 while also stating it has “No
version target_setting, so it stays selected across JDK bumps.” Separately, .bazelrc pins the
repo’s Java runtime/language versions to 25, meaning future upgrades require coordinated updates to
avoid drift.

common/remote-build/java/BUILD.bazel[8-23]
.bazelrc[23-34]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The custom `default_java_toolchain` configuration hard-codes `"java_runtime": "@rules_java//toolchains:remotejdk_25"`. This defeats the goal of being resilient to future JDK bumps and risks version drift or build breakage if the repo’s default JDK changes.

## Issue Context
`.bazelrc` already sets `--java_runtime_version=remotejdk_25` / `--tool_java_runtime_version=remotejdk_25`. If/when the project bumps to a new remote JDK, it’s easy to update `.bazelrc` and forget this BUILD file, leaving workers pinned to 25 or failing if the label changes.

## Fix Focus Areas
- common/remote-build/java/BUILD.bazel[8-16]
- .bazelrc[23-34]

## Suggested change
- Prefer not overriding `java_runtime` at all (inherit it from `DEFAULT_TOOLCHAIN_CONFIGURATION`) and only append the extra `jvm_opts` / `turbine_jvm_opts`.
- If pinning is truly required, update the comment to explicitly state it must be kept in sync with `.bazelrc` during JDK bumps (and consider centralizing the JDK version in one place).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[qodo-code-review]

Code review by qodo was updated up to the latest commit 4aeb51d

[qodo-code-review]

Code review by qodo was updated up to the latest commit d4bdd12

[qodo-code-review]

Code review by qodo was updated up to the latest commit 4204821