C-Libraries in Java nutzen 1: Grundlagen der Foreign Function & Memory API

Javas Foreign Function & Memory API (FFM) dient dazu, auf Code in einer Shared Library beziehungsweise DLL zuzugreifen, der in einer Programmiersprache wie C oder Rust geschrieben ist. Allerdings muss der Code dazu einige Voraussetzungen erfüllen. Diese dreiteilige Artikelserie zeigt anhand einer in C geschriebenen Demo-Library, wie eine Java-Anwendung die Funktionen der Bibliothek aufruft, welche Vorbereitungen erforderlich sind und welche Regeln zu beachten sind. Der Sammelbegriff „Shared Library“ steht in den Artikeln gleichermaßen für eine Shared Library unter Unix wie für eine Windows-DLL.

Rudolf Ziegaus

Rudolf Ziegaus ist Software-Entwickler, Java-Trainer und Geschäftsführer der IO Software GmbH. Seine Lieblingsthemen sind PKi, Kryptographie und systemnahe Programmierung.

Der Ausgangspunkt der Arbeit mit FFM war meine Suche nach einem Weg, per Java auf ein Hardware-Sicherheitsmodul (HSM) zuzugreifen. Da aber noch kein physisches HSM vorhanden war, suchte ich nach einer softwaregestützten Umsetzung. Die Applikation SoftHSM2 lässt sich mit PKCS11 ansprechen, aber der Pkcs#11-Treiber von Sun ist veraltet. Da ich keine passende Open-Source-Anwendung gefunden habe, entwickelte ich selbst einen PKCS11-Wrapper für Java auf Basis der FFM-API.

Da das Projekt sehr umfangreich ist, steht für diese dreiteilige Artikelserie eine eigens entwickelte C-Library im Fokus, die dazu dient, die Konzepte der FFM-API zu erläutern. Die kleine Demo-Library ist auf Windows und Linux getestet.

Ein wenig Historie

In Java gab es vor dem FFM mit dem Java Native Interface (JNI) seit Langem einen Weg, um auf in C geschriebenen Code zuzugreifen. Das JNI war allerdings sehr kompliziert und fehlerbehaftet.

Daher begannen im JDK 14 (Java Development Kit) die Arbeiten an einer neuen Schnittstelle: Foreign Function & Memory API. Die Java-Community hat sie über einige JDK-Versionen und JEPs hinweg verfeinert und schließlich in JDK 22 finalisiert. Allerdings erschien sie im JDK 24 nochmals in veränderter Form. Wegen einiger Breaking Changes ist die API aus Java 24 nicht zu der in Java 22 kompatibel. Dieser Artikel beschreibt die aktuelle Version aus dem JDK 24.

Um die FFM-API zu nutzen, gelten folgende Voraussetzungen:

• Ein JDK ab Version 24 muss installiert sein.
• Das Betriebssystem muss Windows oder Linux auf x64-Basis sein. Die Demo-App sollte auch unter macOS funktionieren, wozu ich aber keine Tests durchgeführt habe.
• Eine Windows-DLL oder eine Shared Library für Linux in 64-Bit-Version muss vorhanden sein.
• Die DLL beziehungsweise Shared Library muss in einer Sprache geschrieben sein, die die C-ABI (Application Binary Interface) unterstützt. Dazu gehören neben C und C++ (mit passend deklarierten Funktionen) auch weitere Sprachen wie Rust und Go.
• Beim Zugriff auf die Shared Library muss man den Native Access erlauben. Das ist aktuell noch ohne Einschränkungen möglich, was sich in einer späteren Java-Version ändern könnte.

Beschreibung der DemoLib

Der Ausgangspunkt für FFM ist immer eine Header-Datei, die in C die Funktionen und gegebenenfalls Typen der Shared Library beschreibt.

Die in C entwickelte Beispiel-Library enthält nur wenige Funktionen und einen Datentyp:

#ifdef _WIN32
  #define EXPORT __declspec(dllexport)
#else
  #define EXPORT
#endif

typedef struct 
{
  double x;
  double y;
} Point;


#define VERSION 1

EXPORT void   initialize(void);
EXPORT int    getVersion(void);
EXPORT void   getVersion2(int *version);
EXPORT long   add(long a, long b);
EXPORT double calcAverage(int *lvalues, int size);
EXPORT double distance(Point *p1, Point *p2);

Es gibt nur eine einzige Typdefinition (Point) und wenige Funktionen. Die Direktive #ifdef im Header-File sorgt dafür, dass sich der Code sowohl unter Linux als auch unter Windows kompilieren lässt.

Toolanbindung mit Stolperfallen

Das Tool jextract hilft beim Zugriff auf native Funktionen. Ausgangspunkt ist auch hier wieder eine Header-Datei, um die notwendigen Zugriffsmethoden für die Funktionen aus der Shared Library zu erzeugen.

jextract kämpft jedoch mit diversen Schwierigkeiten. Zunächst ist es nicht für jedes JDK verfügbar – nach JDK 22 erst wieder für JDK 25. Für die Demo-Library zum Artikel hat die Version aus JDK 22 zwei Klassen generiert: Point für den Zugriff auf die Datenstruktur und DemoLib_h, um auf die Funktionen zuzugreifen. Die Klasse Point hat einen Umfang von etwa 170 schlecht leserlichen Codezeilen, und die Klasse DemoLib_h hat weitere 390 Zeilen Code, die ebenfalls schwer lesbar sind.

Bei komplexen Header-Files ist der Einsatz von jextract noch schwieriger. Beim Versuch, einen Wrapper für PKCS11 zu erzeugen, brach jextract im Zusammenspiel mit dem JDK 22 ab. Die Header-Datei pkcs11.h lädt zwei weitere Header-Dateien nach. Das führte zum Abbruch mit Fehlermeldungen, dass inkompatible Typ-Redefinitionen vorhanden seien.

jextract ist derzeit nur für kleine Projekte einsatzbereit – und auch das mit Einschränkungen. Aufgrund des schwer lesbaren Codes ist es keine Vorlage für eigenen Code. Daher ist der deutlich bessere Ansatz, den Code selbst zu entwickeln und das entsprechende Know-how aufzubauen, um den Code zu verstehen.