The Foreign Function & Memory API
Java 22's modern, safe replacement for JNI: call native code and manage off-heap memory without the old dangers.
On this page
Sometimes Java needs to reach outside the JVM: call a C library, talk to the OS, or manage a big buffer off the garbage-collected heap. For decades that meant JNI (Java Native Interface) - powerful but notoriously error-prone and unsafe. Java 22 finalized a modern replacement: the Foreign Function & Memory API (FFM). You'll rarely use it directly, but knowing it exists and why it's better is senior-level awareness.
Two capabilities
FFM does two related things:
- Foreign functions - call native code (a C library function) directly from Java, without writing C glue code.
- Foreign memory - allocate and access memory outside the Java heap, with explicit, safe lifetime control.
// call the C standard library's strlen on a native string (illustrative)
Linker linker = Linker.nativeLinker();
SymbolLookup stdlib = linker.defaultLookup();
MethodHandle strlen = linker.downcallHandle(
stdlib.find("strlen").orElseThrow(),
FunctionDescriptor.of(JAVA_LONG, ADDRESS));
try (Arena arena = Arena.ofConfined()) { // a scoped memory lifetime
MemorySegment cString = arena.allocateUtf8String("hello");
long len = (long) strlen.invoke(cString); // → 5
} // arena closes: the off-heap memory is deterministically freedWhy it beats JNI
JNI required writing and compiling C boilerplate, was easy to crash the JVM with (bad pointers, memory corruption), and gave no memory-safety guarantees. FFM is:
- Pure Java - no C glue to write or compile.
- Safer - memory access is bounds-checked, and the
Arenagives deterministic, scoped deallocation (atry-with-resources block), avoiding the leaks and use-after-free bugs JNI invited. - Faster to develop and often to run, with the JIT able to optimize across the boundary.
Off-heap memory
The memory half matters on its own: for very large buffers or data shared with native code, keeping it
off the GC heap avoids garbage-collection pressure and gives you precise control over its lifetime.
The Arena abstraction ties that lifetime to a scope, so memory is freed deterministically rather than
whenever the GC decides.
You'll consume it more than write it
Most engineers never call the FFM API directly - but high-performance libraries (data processing, cryptography, ML, database drivers) increasingly use it under the hood to bind to native code safely. Knowing FFM exists explains how modern Java libraries achieve native speed without JNI's dangers, and signals you follow where the platform is heading. It's the successor to sun.misc.Unsafe and JNI both.
JNI was an unmarked back road across the border between Java and native code: you could get there, but there were no guardrails - one wrong turn (a bad pointer) and you crashed, taking the whole JVM with you, and you had to build your own bridge (C glue) to cross. FFM is a modern, official border crossing: documented lanes, guard rails (bounds checks), and a checkpoint that deterministically closes behind you (the Arena freeing memory). You reach the same foreign territory - native libraries and off-heap memory - but safely, in your own language, without hand-building the bridge.
The FFM API allocates off-heap memory through an Arena used in a try-with-resources block, rather than a manual allocate/free pair like C. Explain what class of bugs this design prevents.
Why is the Foreign Function & Memory API (Java 22) preferred over JNI?
Key takeaways
- The Foreign Function & Memory API (finalized Java 22) is the modern, safe replacement for JNI and sun.misc.Unsafe.
- It calls native functions directly and manages off-heap memory - both from pure Java, no C glue.
- It's safer than JNI: bounds-checked access and an Arena that ties memory lifetime to a scope for deterministic deallocation.
- The Arena design prevents leaks, use-after-free, and double-free by removing manual allocate/free.
- Most engineers consume FFM through high-performance libraries rather than writing it - but knowing it exists explains how modern Java binds native code safely.