sun.misc.Unsafe memory-access deprecation (JEP 471): JDK 24+ warns, and future deny-by-default JDKs will break ndarray raw buffers at runtime instead of falling back

[kirillgroshkov]

Investigated and reported by AI, reviewed by me.

---

Summary

sun.misc.Unsafe memory-access methods are terminally deprecated (JEP 471, JDK 23) and JDK 24+ emits a runtime warning on first use (JEP 498). ndarray's raw buffer implementation triggers this warning today, and — more importantly — the way UnsafeReference detects Unsafe availability means that when a future JDK flips the default from warn to deny (planned for JDK 26 or later, see the OpenJDK integrity-by-default roadmap), raw buffers will fail at runtime instead of falling back to the non-Unsafe buffer path.

Current warning (JDK 24/25)

Seen with tensorflow-core-api / ndarray 1.2.0 on JDK 25:

WARNING: A terminally deprecated method in sun.misc.Unsafe has been called
WARNING: sun.misc.Unsafe::arrayBaseOffset has been called by org.tensorflow.ndarray.impl.buffer.raw.UnsafeMemoryHandle (file:.../tensorflow-ndarray-1.2.0.jar)
WARNING: Please consider reporting this to the maintainers of class org.tensorflow.ndarray.impl.buffer.raw.UnsafeMemoryHandle
WARNING: sun.misc.Unsafe::arrayBaseOffset will be removed in a future release

The latent problem: availability check won't detect deny mode

UnsafeReference's static initializer validates the Unsafe methods only by reflective existence check (Class.getDeclaredMethod(...)) — it never actually invokes one:

https://github.com/tensorflow/java/blob/master/tensorflow-ndarray/src/main/java/org/tensorflow/ndarray/impl/buffer/raw/UnsafeReference.java

Under --sun-misc-unsafe-memory-access=deny (the future default), the methods still exist — they just throw UnsupportedOperationException when invoked. So:

1. UnsafeReference.isAvailable() returns true
2. RawDataBufferFactory.canBeUsed() returns true, so callers take the raw-buffer path
3. The first real operation (e.g. UnsafeMemoryHandle.fromArray → Unsafe.arrayIndexScale / arrayBaseOffset, or any getByte/putFloat/copyMemory) throws UnsupportedOperationException at runtime

i.e. instead of degrading gracefully to the heap/nio buffer implementations, applications will start crashing on the first tensor buffer operation once they run on a deny-by-default JDK.

Suggested fixes

• Short term (small change): in UnsafeReference's static initializer, probe by invocation rather than existence — e.g. call unsafe.arrayBaseOffset(byte[].class) inside the existing try and also catch UnsupportedOperationException. Then deny mode cleanly disables raw buffers and the existing fallback path takes over.
• Long term: migrate the raw buffer implementation to VarHandle and/or the Foreign Function & Memory API (java.lang.foreign.MemorySegment), which are the JEP-sanctioned replacements. That also eliminates the startup warning entirely. Once the Unsafe methods are removed (final phase of JEP 471), no JVM flag will keep the current code working.

Workaround for users (for anyone landing here)

• JDK 24/25: --sun-misc-unsafe-memory-access=allow silences the warning.
• Deny-by-default JDKs: --sun-misc-unsafe-memory-access=warn keeps raw buffers functional (the allow value is no longer accepted in that phase).

Environment

• org.tensorflow:tensorflow-core-api:1.2.0 / tensorflow-ndarray:1.2.0
• JDK 25 (warning), any JDK ≥ 24 warns; behavior controlled by --sun-misc-unsafe-memory-access

[Craigacp]

Yep, we need to figure out a plan to deal with this. The short term fix looks fine to me. Now 1.2 has been released we've been considering adopting FFM for the next version, though that will force the baseline Java version to 25 which might be problematic. I'm not sure that VarHandle will provide the right operations to use as a non-25 solution, I'll have to go check.

I'll check what the plan is for that flag, I don't think the flip happened in Java 26, and I can't see it in the list of JEPs for 27 either, which means I suspect the earliest it'll happen is 28.