© Enkel/Shutterstock.com
Java Foreign Memory API und Foreign Linker API

JDK-16-Schnittstellen zur JVM-Anbindung


Seit der Existenz von Java gibt es die Notwendigkeit, auf Bibliotheken und Fremdspeicher zugreifen zu müssen, die mit anderen Programmiersprachen geschrieben wurden. Dies gilt insbesondere für solche, die mit C/C++ entwickelt wurden. Für diese Zugriffe bietet die Java-Plattform nur das Java Native Interface (JNI) an – bis jetzt …

Mittels JNI können die Anwendungen nativen Code enthalten, der in Programmiersprachen wie C/C ++ und in der Programmiersprache Java geschrieben ist. Aus dem Blickwinkel der Java-Plattform ermöglicht das JNI API die Einbindung von Legacy-Code und die Lösung von Interoperabilitätsproblemen zwischen Java-Code und nativ kompiliertem Code (Abb. 1). Die Speicheroperationen sind nicht unproblematisch, weil nativer Code ausgeführt wird, verwendete Objekte wieder freigegeben werden müssen und zwischen den nativen Aufrufen direkt wieder zur Java-Anwendung zurückgekehrt wird, ohne dabei mögliche Fehler im Native-Code erkennen zu können.

Projekt Panama

Zur besseren Entwicklerunterstützung bei der Bewältigung dieser Programmieraufgabe wurde das Projekt Panama [1] geschaffen. Es dient dazu, Interaktion zwischen JVM und Native-Code zu erleichtern. Die Verbindungen zwischen der JVM und den wohldefinierten Non-Java-Schnittstellen (Foreign APIs) wurden dafür überarbeitet – insbesondere den APIs, die üblicherweise von C-Programmierern verwendet werden. Das Projekt Panama enthält die JDK Enhancement Proposals zum Foreign Memory Access API (JEP-383) [2], das Foreign Linker API (JEP-389) [3] sowie das Vector API (JEP-338) und die folgenden Komponenten:

  • nativer Funktionsaufruf der JVM

  • nativer Datenzugriff der JVM oder innerhalb des JVM Heap

  • neue Datenlayouts im JVM Heap

  • native Metadatendefinition für die JVM

  • API-Extraktionstools für Headerdateien (jextract)

  • native Bibliotheksverwaltungs-APIs

  • nativ orientierter Interpreter und Laufzeit-Hooks

  • Klassen- und Methodenauflösungs-„Hooks“

  • nativorientierte JIT-Optimierungen

  • Werkzeuge oder Wrapper zur Einhaltung von Sicherheitsmerkmalen

  • Arbeitsfortschritte bei schwer zu integrierenden nativen Bibliotheken

Foreign Memory Access API

Mit dem Foreign Memory Access API in seiner dritten Inkubationsauflage ist der JEP 393 Bestandteil von JDK 16 [4]. Das API ermöglicht Java-Programmen den sicheren Zugriff auf fremden Speicher außerhalb des Java Heaps. Dabei wurde eine klare Rollentrennung zwischen den Interfaces MemorySegment und MemoryAddress geschaffen. Das neue Interface MemoryAccess beinhaltet allgemeine statische Memory-Zugriffsfunktionen und minimiert den Einsatz des VarHandle API in einfachen Fällen. Gemeinsam genutzte Speichersegmente werden unterstützt und die Segmente bieten die Möglichkeit, sie mit einem Cleaner zu registrieren.

Generell soll die Schnittstelle in der Lage sein, mit verschiedenen Arten von Foreign Memory, wie Native Memory, Persistent Memory und Managed Heap Memory zusammenzuarbeiten. Es soll vermieden werden, dass das API die JVM-Sicherheit untergräbt, unabhängig von der Art des Speichers, mit dem gerade gearbeitet wird. Die Clients sollen Kontrollmöglichkeiten haben, beispielsweise sollen Speichersegmente wieder freigegeben werden – entweder explizit über einen Methodenaufruf oder implizit, wenn das Segment nicht mehr verwendet wird. Für Anwendungsprogramme, die auf Foreign Memory zugreifen müssen, soll das API eine brauchbare Alternative zu älteren Java APIs wie sun.misc.Unsafe sein. Eine Reimplementierung veralteter Java APIs wie sun.misc.Unsafe ist jedoch nicht vorgesehen.

schoenefeld_weigend_foreign_1.tif_fmt1.jpgAbb. 1: Java-Applikationsaufruf von Native-C/C++-Code via JNI

Der bisherige Ansatz mit JNI

Bereits seit frühen JDK-Versionen wie Java 1.1 existiert mit dem Java Native Interface (JNI) eine standardisierte Vorgehensweise zur Anbindung nativer Bibliotheken. Im Gegensatz zur fortschreitenden Innovation des JDK von Version zu Version (Coin, Lambda, Java-Module-System), hat sich das Arbeiten mit dem JNI softwaretechnisch nicht weiterentwickelt und setzt beim Programmierer Kenntnisse in C und C++ mit den dazugehörigen Tools voraus. Die hohen Einstiegshürden und d...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang