Java einfach erklärt

Plain Java

Die Foreign Function & Memory API in Java 22 – Native Performance ohne JNI

Mit der Veröffentlichung von Java 22 hat die Foreign Function & Memory (FFM) API endgültig den Status einer stabilen, produktionsreifen Schnittstelle erreicht. Sie ermöglicht es Java-Entwickler:innen, auf einfache, sichere und performante Weise auf native Bibliotheken und Speicherbereiche außerhalb der Java-Heap-Struktur zuzugreifen. Damit löst sie teilweise das traditionelle Java Native Interface (JNI) ab, das lange Zeit der Standardweg für die Interaktion mit C- oder C++-Code war. In diesem Artikel beleuchten wir die Kernkonzepte der FFM-API, zeigen praxisnahe Beispiele und vergleichen sie eingehend mit JNI.

Grundlagen der Foreign Function & Memory API

Die FFM-API verfolgt zwei zentrale Ziele:

  1. Native Funktionen aufrufen: Java-Code kann Methoden aus nativen Bibliotheken aufrufen, ohne auf komplexe JNI-Schnittstellen angewiesen zu sein.
  2. Memory Management außerhalb des Heaps: Entwickler:innen können Speicherbereiche erstellen, lesen, schreiben und wieder freigeben, die außerhalb der von der JVM verwalteten Heap-Struktur liegen.

Die FFM-API arbeitet dabei hauptsächlich mit drei Bausteinen:

  • MemorySegment: Repräsentiert einen zusammenhängenden Speicherbereich, vergleichbar mit einem Zeiger auf ein Array in C.
  • MemoryAddress: Stellt eine konkrete Adresse im Speichersegment dar.
  • CLinker und FunctionDescriptor: Helfen beim Mapping von Java-Typen auf native Funktionssignaturen.

Ein zentrales Konzept ist die Sicherheitskontrolle: Im Gegensatz zu JNI sorgt die FFM-API dafür, dass Speicherlecks und Speicherverletzungen reduziert werden, indem Segmentgrenzen und Typen strikt geprüft werden.

Ein einfaches Beispiel: Aufruf einer C-Funktion

Angenommen, wir haben eine C-Bibliothek mit folgender Funktion:

// mathlib.c
int add(int a, int b) {
    return a + b;
}
Code-Sprache: JavaScript (javascript)

Der klassische JNI-Ansatz würde zunächst das Erstellen von Header-Dateien, das Schreiben einer nativen Implementierung in C und das Kompilieren der Bibliothek erfordern. Anschließend müsste Java die System.loadLibrary-Methode aufrufen und die nativen Methoden deklarieren:

public class JNIMath {
    static { System.loadLibrary("mathlib"); }
    public native int add(int a, int b);
}
Code-Sprache: PHP (php)

Mit der FFM-API in Java 22 geht das wesentlich direkter und ohne Boilerplate-Code:

import java.lang.foreign.*;
import java.lang.invoke.*;

public class FFMMath {
    public static void main(String[] args) throws Throwable {
        System.loadLibrary("mathlib");

        SymbolLookup lib = SymbolLookup.libraryLookup("mathlib", SymbolLookup.loaderLookup());
        MethodHandle add = CLinker.systemCLinker()
            .downcallHandle(
                lib.lookup("add").get(),
                MethodType.methodType(int.class, int.class, int.class),
                FunctionDescriptor.of(CLinker.C_INT, CLinker.C_INT, CLinker.C_INT)
            );

        int result = (int) add.invokeExact(5, 7);
        System.out.println("5 + 7 = " + result);
    }
}
Code-Sprache: JavaScript (javascript)

Hierbei übernimmt FFM die Typenprüfung, die korrekte Konvertierung zwischen Java- und C-Typen sowie das Exception-Handling auf nativer Ebene, was den Code wesentlich sicherer und wartbarer macht.

Arbeit mit nativen Speicherbereichen

Neben dem Funktionsaufruf bietet die FFM-API auch komfortable Werkzeuge für den Umgang mit Speicher außerhalb des Java-Heaps:

try (MemorySegment segment = MemorySegment.allocateNative(4 * Integer.BYTES)) {
    VarHandle intHandle = MemoryHandles.varHandle(int.class, ByteOrder.nativeOrder());
    for (int i = 0; i < 4; i++) {
        intHandle.set(segment, i * Integer.BYTES, i + 1);
    }

    for (int i = 0; i < 4; i++) {
        int value = (int) intHandle.get(segment, i * Integer.BYTES);
        System.out.println("Wert an Position " + i + ": " + value);
    }
}
Code-Sprache: JavaScript (javascript)

Mit MemorySegment.allocateNative wird ein nativer Speicherblock alloziert, der nach Verlassen des try-with-resources-Blocks automatisch freigegeben wird. So entfällt das manuelle Freeen des Speichers, wie es bei JNI erforderlich wäre.

Vergleich FFM vs. JNI

1. Boilerplate und Lesbarkeit

  • JNI erfordert Header-Generierung, explizite native-Methoden, manuelles Kompilieren von C/C++-Code und sorgfältiges Memory Management.
  • FFM erlaubt direkte Definitionen von MethodHandles, Symbol-Lookups und nativen Speicherzugriffen innerhalb von Java selbst. Der Code ist kürzer, klarer und einfacher zu warten.

2. Sicherheit

  • JNI ist anfällig für Speicherlecks, Buffer-Overflows und typbedingte Fehler.
  • FFM arbeitet mit MemorySegments und VarHandles, die Bounds-Checks und Typüberprüfungen automatisch durchführen. Das Risiko von Segmentation Faults wird reduziert.

3. Performance

  • JNI hat eine geringe, aber spürbare Overhead-Schicht, da die JVM und der native Code über Brücken kommunizieren.
  • FFM ist ebenfalls sehr performant und erlaubt Compiler-Optimierungen wie Inlining von Funktionsaufrufen. Bei manchen Workloads kann es sogar schneller sein, weil weniger Boilerplate ausgeführt wird.

4. Wartbarkeit

  • JNI erfordert Synchronisierung zwischen Java- und C-Code, was bei Änderungen in der nativen Bibliothek zu Kompatibilitätsproblemen führen kann.
  • FFM erlaubt, dank deklarativer FunctionDescriptor-Typen, eine klarere Spezifikation der Schnittstellen, die leichter zu refaktorieren sind.

5. Speicherverwaltung

  • JNI: Entwickler:innen müssen Speicher manuell freigeben (malloc/free) und auf Garbage Collection achten.
  • FFM: Automatisches Schließen von MemorySegment via try-with-resources reduziert das Risiko von Speicherlecks erheblich.

Praktische Anwendungsbereiche

Die FFM-API eignet sich besonders für:

  • Hochperformante Numerik, z. B. KI- oder Bildverarbeitungsbibliotheken in C/C++.
  • Zugriff auf Systembibliotheken, z. B. POSIX-Funktionen oder Windows-APIs.
  • Interaktion mit bestehendem Legacy-Code, ohne JNI-Wrapper schreiben zu müssen.
  • Low-Level-Netzwerkprogrammierung oder Speicherpuffer-Verwaltung für I/O-intensive Anwendungen.

Fazit

Die Foreign Function & Memory API in Java 22 stellt einen bedeutenden Fortschritt gegenüber JNI dar. Sie vereinfacht die Nutzung nativer Funktionen, erhöht die Sicherheit beim Speicherzugriff und macht den Code leichter wartbar. Während JNI weiterhin existiert und in bestimmten Legacy-Szenarien unverzichtbar ist, empfiehlt sich für neue Projekte der FFM-Ansatz, da er eine moderne, klar typisierte und speichersichere Alternative bietet.

Durch die Kombination aus MethodHandles, MemorySegments und deklarativen FunctionDescriptors bietet die FFM-API eine flexible und performante Möglichkeit, Java und native Bibliotheken effizient zu verbinden – ohne die Komplexität und Fehleranfälligkeit des traditionellen JNI-Ansatzes.