Java Academy · Lektion

Warum FFM statt JNI

Sicherere native Interoperabilität

Warum FFM statt JNI ist eine kostenlose Java Academy-Lektion auf CoddyKit. Dies ist Lektion 1 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Java Academy-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Java Academy-Kurs umfasst insgesamt 4 Lektionen.

Nativen Code aufrufen

Java muss manchmal C-Bibliotheken aufrufen oder mit Speicher außerhalb des Heaps arbeiten. Der klassische Ansatz war das Java Native Interface (JNI). Der moderne Ansatz ist die Foreign Function and Memory API (FFM), die in Java 22 (JEP 454) finalisiert wurde.

In dieser Lektion erfahren Sie, warum FFM die bessere Wahl ist.

Was JNI erforderte

JNI war umständlich:

C-Klebecode mit unhandlichen JNIEXPORT-Signaturen schreiben
Für jede Plattform eine native Shared Library kompilieren
Zwischen Java- und C-Typen manuell konvertieren
Die JVM durch einen Fehler leicht zum Absturz bringen

FFM ist reines Java

Mit FFM können Sie native Funktionen aufrufen und auf nativen Speicher zugreifen, vollständig aus Java heraus. Kein C-Klebecode, kein separater Kompilierungsschritt und kein manuell geschriebener Marshalling-Code.

Sie beschreiben die Signatur der nativen Funktion in Java und rufen sie über einen Method Handle auf.

Die wichtigsten Pakete

Alles befindet sich in java.lang.foreign. Die zentralen Typen sind:

Linker und SymbolLookup zum Finden und Binden von Funktionen
MemorySegment für nativen Speicher
Arena für eine deterministische Lebensdauer
MemoryLayout und FunctionDescriptor zur Beschreibung von Strukturen

Sicherheit von Anfang an

FFM ist deutlich sicherer als JNI:

Speicherzugriffe mit Grenzprüfung
Die Lebensdauer ist an eine Arena gebunden, sodass Use-after-free erkannt wird
Die Thread-Bindung verhindert unsichere threadübergreifende Zugriffe

Fehler lösen Java-Ausnahmen aus, statt die VM zum Absturz zu bringen.

Ein Vorgeschmack auf die API

Diese Skizze findet die C-Funktion strlen und bereitet ein Handle für sie vor. Entscheidend ist, dass dies vollständig gewöhnlicher Java-Code ist.

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

public class Main {
    public static void main(String[] args) {
        Linker linker = Linker.nativeLinker();
        SymbolLookup stdlib = linker.defaultLookup();
        MethodHandle strlen = linker.downcallHandle(
            stdlib.find("strlen").orElseThrow(),
            FunctionDescriptor.of(ValueLayout.JAVA_LONG, ValueLayout.ADDRESS));
        System.out.println("Bound a handle to strlen: " + strlen);
    }
}

Leistung

FFM-Downcalls können mit JNI mithalten und sind oft schneller, weil der JIT-Compiler die generierten Stubs inline einfügen und optimieren kann. Pro Aufruf muss kein C-Trampolin durchlaufen werden.

Nativen Zugriff aktivieren

Da nativer Code gefährlich sein kann, kann FFM eine Warnung ausgeben oder eine ausdrückliche Freigabe verlangen. Sie gewähren den Zugriff beim Start mit --enable-native-access=ALL-UNNAMED (oder einem bestimmten Modulnamen), um Warnungen zu unterdrücken.

sun.misc.Unsafe ersetzen

FFM (zusammen mit der Memory API) ist außerdem der offiziell vorgesehene Ersatz für die seit Langem veralteten Off-Heap-Operationen von sun.misc.Unsafe. Bibliotheken, die native Puffer manuell verwalten, können auf sichere, unterstützte APIs umsteigen.

Werkzeuge: jextract

Bei großen C-Bibliotheken liest das Begleitwerkzeug jextract eine C-Headerdatei ein und generiert automatisch die Java-FFM-Bindings. Sie müssen Deskriptoren nicht von Hand schreiben.

Es ist das Produktivitätsgegenstück zu FFM – ähnlich wie ein Codegenerator.

Wann Sie FFM verwenden sollten

Verwenden Sie FFM, wenn Sie:

eine vorhandene C/C++-Bibliothek aufrufen müssen
auf niedriger Ebene mit dem Betriebssystem interagieren müssen
große Off-Heap-Puffer effizient verwalten müssen

Für reine Java-Anwendungen benötigen Sie es nie.

Kurzer Test

Rufen Sie sich den wichtigsten Vorteil gegenüber JNI ins Gedächtnis.

Zusammenfassung

Sie haben gelernt, warum FFM JNI überlegen ist:

Reines Java ohne C-Verbindungscode oder zusätzliche Kompilierung
Sicher dank Grenzprüfungen, Arena-Lebensdauern und Thread-Bindung
Vergleichbare oder bessere Leistung
Ersetzt sun.misc.Unsafe und ergänzt sich mit jextract

Als Nächstes: nativen Speicher mit MemorySegment und Arena verwalten.

Häufig gestellte Fragen

Ist die Lektion „Warum FFM statt JNI“ kostenlos?

Ja — der vollständige Text von „Warum FFM statt JNI“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Java Academy-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Java Academy-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Warum FFM statt JNI“?

Sicherere native Interoperabilität Du übst Java Academy mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um Java Academy zu starten?

Keine Vorkenntnisse erforderlich. Java Academy auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 1 von 4.

Wie lange dauert die Lektion „Warum FFM statt JNI“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser Java Academy-Lektion Code schreiben und ausführen?

Ja. Jede Java Academy-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

← Zurück zu Java Academy