`header_compiler_direct` (TurbineDirect) emits protobuf `sun.misc.Unsafe` warnings on JDK 24+ that no toolchain option can silence

[davido]

Description

When header compilation runs on a JDK 24+ runtime, every direct-header compilation prints:

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
         (.../java_tools/turbine_direct_binary_deploy.jar)
WARNING: Please consider reporting this to the maintainers of class com.google.protobuf.UnsafeUtil
WARNING: sun.misc.Unsafe::arrayBaseOffset will be removed in a future release

TurbineDirect bundles protobuf, whose UnsafeUtil calls the terminally deprecated sun.misc.Unsafe memory-access methods; on JDK 24+ (JEP 498) the JVM warns by default (mode warn). Root cause of the Unsafe usage is protocolbuffers/protobuf#20760.

Why it can't be silenced today

The obvious fix — --sun-misc-unsafe-memory-access=allow — cannot be routed to the TurbineDirect JVM from a toolchain:

• turbine_jvm_opts is passed only to the Turbine worker
  (header_compiler), not to header_compiler_direct
  (java/common/rules/java_toolchain.bzl: header_compiler gets
  turbine_jvm_opts; header_compiler_direct gets a separately-computed
  header_compiler_direct_jvm_opts that is hardcoded to
  ["-Dturbine.ctSymPath=…"]).
• --jvmopt applies to java_binary/java_test execution, not to
  header-compilation actions (verified with aquery: the flag does not appear
  in the TurbineDirect command line).
• header_compiler_direct_jvm_opts is not exposed as a java_toolchain /
  default_java_toolchain attribute, and header_compiler_direct cannot be
  dropped (rules_java fail()s when header compilation is requested without it).

So a downstream project on JDK 24+ (e.g. Gerrit Code Review) has no supported way to quiet the warning.

Bazel itself tracks protobuf#20760 per-tool (its root BUILD adds the flag to turbine_jvm_opts;

import_deps_checker adds it to jvm_flags; commit a121ec75d2 narrowed a global --jvmopt down to import_deps_checker), but none of those cover the header_compiler_direct header-compilation path — so the warning surfaces for every rules_java consumer building Java on JDK 24+.

Reproduction

Any java_library built with a toolchain whose java_runtime is JDK 24+.

bazel aquery 'mnemonic("Turbine", //your:lib)' shows the TurbineDirect command carries only -Dturbine.ctSymPath=… and a fixed set of --add-opens — no way to add --sun-misc-unsafe-memory-access=allow.

Proposed fix (see the PR)

Add --sun-misc-unsafe-memory-access=allow to header_compiler_direct_jvm_opts in _java_toolchain_impl, gated on the runtime feature version (the flag is rejected on JDK ≤ 22, so it must be version-guarded; java_runtime.version is 0 when unknown):

if java_runtime and java_runtime.version >= 24:
    header_compiler_direct_jvm_opts = header_compiler_direct_jvm_opts + [
        "--sun-misc-unsafe-memory-access=allow",
    ]

Verified with aquery against a JDK-25 toolchain (the flag now appears in the TurbineDirect command) and a JDK-21 toolchain (the flag is correctly omitted, so the JVM still starts). This fixes it once for all consumers instead of requiring each project to work around it — and the obvious per-project workaround (turbine_jvm_opts) does not even reach the direct header compiler.

Environment

• rules_java 9.8.0 (bundled remote_java_tools TurbineDirect)
• JDK 24+ runtime (e.g. remotejdk_25)
• Related: Warnings about terminally deprecated Unsafe usage protocolbuffers/protobuf#20760 (root cause), JEP 498

[cushon]

Are you seeing this with a non- native-image build of turbine?

I think this is also using a version of protobuf before https://github.com/protocolbuffers/protobuf/releases/tag/v34.0, which has some changes in this area. I thought that maybe non-lite proto wouldn't result in the warnings after that, but maybe it just results in different warnings (protocolbuffers/protobuf@3514901, protocolbuffers/protobuf@1041d62)

[davido]

Are you seeing this with a non- native-image build of turbine?

Yes — the build uses the JVM deploy jar turbine_direct_binary_deploy.jar, not the turbine_direct_graal native image.

I think this is also using a version of protobuf before https://github.com/protocolbuffers/protobuf/releases/tag/v34.0,

I pulled turbine_direct_binary_deploy.jar straight from the java_tools v20.0 release (what rules_java 9.8.0 ships) and read its bundled RuntimeVersion: it's protobuf 4.35.1, i.e. already past v34.0 — not 4.33.x. So the version hypothesis doesn't apply here; turbine already has current protobuf. And it still warns — running that exact shipped jar on JDK 25:

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 (…/turbine_direct_binary_deploy.jar)
WARNING: Please consider reporting this to the maintainers of class com.google.protobuf.UnsafeUtil
WARNING: sun.misc.Unsafe::arrayBaseOffset will be removed in a future release

protobuf 4.35.1's UnsafeUtil still calls sun.misc.Unsafe::arrayBaseOffset (protobuf#20760 is still open — no VarHandle migration yet), so the protobuf version was never the lever. This is about the direct header compiler passing --sun-misc-unsafe-memory-access=allow (rules_java#374).

For the record, here's exactly what rules_java 9.8.0 pulls in on the header-compilation path — everything is current:

• rules_java: 9.8.0
• → java_tools: v20.0 (released 2026-08-11)
• → built from bazel commit: 5dc60cedd5456112b1c21c577f94c041230be3ff (2026-08-10)
• → protobuf pin at that commit: 35.1 → turbine_direct_binary_deploy.jar bundles protobuf-java 4.35.1 (confirmed from the release artifact's RuntimeVersion: MAJOR=4, MINOR=35, PATCH=1)
• Remote JDKs, all bumped to the latest Zulu in Update remotejdk_21 to Zulu 21.0.12 #370 (4e79508, 2026-08-10, Fixes remotejdk_21 (Zulu 21.0.9) lacks the JDK-8341779 backport, causing Error Prone false positives #369): remotejdk_21 = Zulu 21.52.15 / 21.0.12, remotejdk_25 = Zulu 25.36.15 / 25.0.4 (also 8.0.502, 11.0.32, 17.0.20).
• turbine: com.google.turbine:turbine:1.15.0

FWIW to reproduce end-to-end: clone Gerrit recursively, fetch [1], then bazel build headless.

[1] https://gerrit-review.googlesource.com/c/gerrit/+/619806