Ein 64-Byte-Segment lässt sich per asSlice in Java-FFM so aufteilen, dass die letzten 16 Byte ohne Kopie als View zugänglich sind. Das ist effizient, führt aber schnell zu Fehlern, wenn native Pointer ohne Längeninformation zurückkommen. Java 22 hat die Foreign Function & Memory API seit März 2024 aus dem Preview-Status genommen. Im dritten Teil seiner Heise-Reihe erklärt Rudolf Ziegaus konkrete Werkzeuge und typische Fallen beim produktiven Einsatz, etwa MemorySegment.asSlice und die Nutzung von reinterpret, sowie Codebeispiele und Hinweise zur Plattformkompatibilität.

Die Foreign Function & Memory API, kurz FFM, ist in Java 22 als Standard verfügbar und verschiebt die Schnittstellenarbeit zwischen Java und nativem Code weg vom C-Glue, hin zu einem Java-seitigen Modell. Heise-Autor Rudolf Ziegaus stellt FFM als den praktikableren Weg dar, wenn der native Quellcode nicht verändert werden soll oder kein zusätzlicher C-Code gewünscht ist. Zentral für FFM ist das Konzept des MemorySegment: ein explizites Objekt, das Speicherbereiche repräsentiert, Lebenszyklen regelt und Views erlaubt.

Ein wichtiges Werkzeug ist MemorySegment.asSlice. Es erzeugt eine View auf einen Teilbereich eines bereits allozierten Segments, ohne Daten zu kopieren. Änderungen an der View wirken direkt auf das ursprüngliche Segment. Ziegaus illustriert das mit einem konkreten Beispiel: Ein 64-Byte-Segment, aus dem mit asSlice(48, 16) die letzten 16 Byte als neues Segment-Objekt gewonnen werden. Das ist effizient, aber es verlangt Disziplin beim Umgang mit Lebensdauer und Alignment.

Ein besonders heimtückischer Fall tritt auf, wenn native Funktionen einen void*-Pointer zurückgeben, der in FFM initial als Segment mit Länge 0 erscheint. Ein direkter Zugriff auf ein solches Segment löst in Java schnell eine ArrayIndexOutOfBoundsException aus. Ziegaus empfiehlt deshalb, die Segment-Länge vor dem Zugriff mit reinterpret explizit zu setzen, sofern die korrekte Länge bekannt ist. Reinterpret ermöglicht es, die Wahrnehmung eines Segments zu verändern, ohne den zugrundeliegenden Speicher zu kopieren, und ist damit ein pragmatisches Mittel, um native APIs mit impliziter Längeninformation zu adaptieren.

Wichtig ist zudem, dass asSlice und reinterpret keine Speicherbesitzfrage lösen. Sie geben Views und Anpassungen, aber nicht automatisch Ownership. Wer mit native Allocatoren und Java-verwalteten Segmenten mischt, muss klare Vereinbarungen über Lifetimes treffen, sonst drohen Use-after-free-Situationen oder Speicherlecks.

Die Arbeit mit nativen Bibliotheken ist nicht nur eine Frage der API, sondern auch des Build-Umfelds und der Plattform. Typengrössen wie long int variieren zwischen Betriebssystemen und Toolchains. Ein Beispiel, das Ziegaus nennt, ist die Differenz zwischen Linux x86_64, wo bestimmte nativen Typen 64 Bit breit sind, und einigen Windows-Implementierungen, in denen dieselben Typen 32 Bit breit sein können. Das hat direkte Folgen für die Signaturbeschreibung in FFM oder in Alternativen wie JNA.

Mastheads

Wer die falsche Breite angibt, riskiert Speicherüberschreibungen oder inkorrekte Werte.

Praktisch bedeutet das: Die C-Bibliothek muss für die Zielplattform kompiliert und gegen dieselben Laufzeitbibliotheken gelinkt werden, weil unterschiedliche C-Laufzeit-Implementierungen wie glibc oder musl zu Inkompatibilitäten führen können. Statisches Einbinden löst manche Konflikte nicht vollständig, da Libraries in einer gemeinsam genutzten Umgebung weiterhin kompatibel bleiben müssen. Deshalb ist das Testen auf allen Zielplattformen keine Komfortübung, sondern Pflicht.

Aus diesen Beobachtungen leitet Ziegaus implizite Best Practices ab. Erstens klare Vereinbarungen über Speichergrössen und Ownership zwischen Java- und nativen Komponenten. Zweitens das konsequente Setzen von Alignment und Typgrössen beim Mapping nativer Strukturen in Java, damit Feldoffset und Layout übereinstimmen. Drittens umfassende Tests auf allen Zielplattformen, inklusive verschiedener C-Laufzeitbibliotheken und Compilerversionen.

Slicing und reinterpret sind mächtige Werkzeuge, bergen aber Risiken, wenn Längen, Alignment oder Lebensdauer falsch behandelt werden. In vielen Fällen ist FFM trotzdem der praktischere Weg: Es entfällt die native Glue-Schicht, weniger Boilerplate entsteht, und Wartung sowie Debugging werden einfacher als bei reinen JNI-Lösungen.

Als Alternativen nennt die Reihe JNA und JNI: JNA bietet dynamischen Zugriff ohne zusätzlichen C-Code, während JNI maximalen Kontrollgrad erlaubt, aber mit erheblichem Boilerplate- und Fehlerpotenzial verbunden ist. FFM versucht die Vorteile eines Java-zentrierten Entwicklungspfads zu verbinden mit der Notwendigkeit, systemnahe Details zu verstehen.

Für Produktionsprojekte heisst das konkret: Konsens über native Typdefinitionen, ein wiederholbares Build der nativen Bibliotheken für jede Zielplattform, und Instrumentierung der Java-Seite, um Segment-Lifetimes explizit zu überwachen. Codebeispiele in der Heise-Reihe zeigen, wie asSlice und reinterpret korrekt eingesetzt werden. Wer diese Regeln beachtet, gewinnt die Effizienzvorteile von FFM ohne die klassischen JNI-Fallen.

Die Serie richtet sich an Entwicklerteams, die bereits native Bibliotheken nutzen oder legacy C-APIs integrieren müssen. Sie setzt kein Rewriting des nativen Codes voraus, wohl aber disziplinierte Schnittstellendefinitionen und Testprozesse.

Related Articles

Das 64-Byte-Beispiel, aus dem asSlice(48, 16) die letzten 16 Byte als View erzeugt, fasst die Stärke und die Gefahr von FFM zusammen: hohe Effizienz bei gleichzeitig enger Verknüpfung von Länge, Alignment und Lebensdauer. Die Foreign Function & Memory API ist seit März 2024 in Java 22 Standard; wer sie produktiv nutzt, braucht klare Ownership-Regeln, plattformübergreifende Builds und umfassende Tests.

Dieser Artikel wurde mit KI-Unterstützung erstellt.