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.

Nachdem der erste Teil gezeigt hat, wie man in Java eine in C geschriebene Shared Library lädt und einfache Funktionen dieser Shared Library aufruft, geht es jetzt um komplexere Szenarien. Er zeigt, wie man aus Java Funktionen mit veränderbaren Parametern aufrufen und Arrays sowie Strukturen übergeben kann.

Funktionen mit veränderbarem Parameter

Die bisherigen Beispiele haben die Aufrufe der nativen Funktionen einfach gehalten. Die Java-Anwendung hat lediglich Parameter durchgereicht und den Rückgabewert übernommen.

Anders sieht es bei den nächsten Beispielen aus. Als erstes folgt die einfache C-Funktion getVersion2, die wie die Funktion getVersion aus Teil 1 die Version der Library ermittelt. Die neue Funktion gibt die Versionsnummer aber nicht als Wert zurück, sondern verändert dazu einen Parameter. Das funktioniert in C, indem eine Anwendung für einen Parameter nicht den Wert selbst, sondern dessen Adresse übergibt (Call by Reference). Dieses Konstrukt sieht in C folgendermaßen aus:

EXPORT void   getVersion2(int* version);

Folgender Java-Code ruft die Funktion auf:

int version;
getVersion2(&version);

Das & kennzeichnet in C, dass die Funktion die Adresse der Variablen nutzt. Java erlaubt das Vorgehen nicht, sodass ein Rückgabewert unerlässlich ist. Folgende Java-Methode verwendet die C-Funktion mit Referenz:

public int getVersion2() throws Throwable
{
  MethodHandle method = getMethodHandle("getVersion2",   
     FunctionDescriptor.of(
				ValueLayout.JAVA_INT, 
				ValueLayout.ADDRESS
				));
  try (Arena arena = Arena.ofConfined())
  {
    MemorySegment versionSeg =   
      arena.allocate(ValueLayout.JAVA_INT.byteSize());
    method.invoke(versionSeg);
    int version = versionSeg.get(ValueLayout.JAVA_INT, 0);
    return version;
  }
}

Zuerst ruft der Code wie im ersten Teil der Serie wieder die Methode getMethodHandle() auf. Der Aufruf definiert den FunctionDescriptor für die Funktion getVersion2().

Die Angabe ValueLayout.ADDRESS für den Parameter zeigt an, dass die C-Funktion eine Adresse erwartet.

Jetzt kommt der spannendere Teil: Um eine Adresse übergeben zu können, muss die Java-Anwendung mittels der FFM-API einen Speicherbereich von vier Byte (für den Datentyp int) reservieren. Das geschieht mit einer Arena, die er erste Teil bereits erläutert hat. Das Erzeugen der Arena mit dem try-with-ressources-Statement stellt sicher, dass die Arena nach dem try-Block automatisch geschlossen und der darin verwaltete Speicher automatisch freigegeben wird. Es gibt verschiedene Typen von Arenas – die im Beispiel über ofConfined erzeugte sorgt dafür, dass die Anwendung nur auf Speicher des aktuellen Thread zugreifen kann. Eine mit ofConfined() erzeugte Arena – beziehungsweise der damit allozierte Speicher – ist daher nicht threadsicher.

Als nächstes gilt es, den erforderlichen Speicherbereich für den Parameter version zu allokieren. Dafür besitzt die Arena die Methode allocate(). Die Größe des benötigten Speichers kann man durch die Funktion byteSize() für die Variable ermitteln. Hier sei nochmals darauf hingewiesen, dass der Wert die Größe des Java-Datentyps darstellt und nicht zwingend etwas über den C-Datentyp aussagt. Da die C-Funktion einen int-Parameter entgegennimmt, sind wir auf der sicheren Seite, da int in C stets vier Byte umfasst. Bei einem long-Wert in C hängt die Größe dagegen von der Plattform ab.

Der Speicherbereich wird durch ein MemorySegment dargestellt, das beim Aufruf der Methode invoke an die C-Funktion weitergereicht werden muss.

Anschließend kann die Anwendung das Ergebnis auslesen. Dazu ruft sie auf dem MemorySegment die Funktion get auf und übergibt ihr das Layout des Speichers (in diesem Fall ein JAVA_INT) und den Offset zum Lesen aus dem MemorySegment. Für das Beispiel ist der Offset null. Durch die Angabe JAVA_INT gibt die Funktion einen int-Wert zurück, den die Anwendung weiterverarbeiten kann.

Funktionen mit einem Array-Parameter

Die nächste Aufgabe baut auf dem Vorgehen auf, verarbeitet aber nicht nur einen Wert, sondern ermittelt den Durchschnitt aus einer Liste von int-Werten. Dazu muss sie der nativen Funktion ein Array von int-Werten übergeben:

public double calcAverage(int [] values) throws Throwable
{
  MethodHandle calcAverage =  
     getMethodHandle("calcAverage"),
	    FunctionDescriptor.of(
	    ValueLayout.JAVA_DOUBLE,     // return value 
	    ValueLayout.ADDRESS,         // data values 
	    ValueLayout.JAVA_INT));      // number of elements

  try(Arena arena = Arena.ofConfined())  
  {
    long totalSize = ValueLayout.JAVA_INT.byteSize() * values.length;
    MemorySegment valueSegment = arena.allocate(totalSize);
    for (int i = 0; i < values.length; i++) 
    {
      valueSegment.setAtIndex(ValueLayout.JAVA_INT, i, values[i]); 
    }
    double result = (double) calcAverage.invoke(valueSegment, 
                                                values.length);
    return result;
  }
}

Zunächst berechnet der Code die gesamte Speichergröße des Arrays (totalSize) und reserviert den benötigten Speicher mit allocate(). Anschließend belegt der Code den Speicher mit der Methode setAtIndex für das jeweilige MemorySegment. Der Aufruf erfolgt für jedes Element des Arrays.

Schließlich ruft der Code die Methode invoke für den MethodHandle auf und übergibt ihr als Parameter das Array und dessen Länge. Schließlich gibt sie das Ergebnis der C-Funktion zurück.

Ende dieses Jahres werde es schätzungsweise nur noch 25,6 Millionen Prepaid-Karten in Deutschland geben und damit rund sieben Prozent weniger als 2025, heißt es in einer Marktstudie des Internet-Branchenverbandes VATM. In den vergangenen beiden Jahren waren die Rückgänge mit neun beziehungsweise zehn Prozent noch kräftiger ausgefallen. Im Jahr 2023 hatte es im Bundesgebiet den Angaben zufolge noch 33,6 Millionen Prepaid-Sim-Karten gegeben. Ein Teil dieser Handys schlummert ungenutzt in den Schubladen.

Bei Prepaid-Karten zahlt der Nutzer vorab Geld ein, damit er eine Handyverbindung bekommt. Ist das Guthaben aufgebraucht, ist Schluss. Anders ist es bei „Postpaid“. Hierbei unterschreibt man einen Vertrag und zahlt dann im Monatsrhythmus Geld. Solche SIM-Karten sind im Aufwind, laut der vom VATM in Auftrag gegebenen Studie des Beratungsunternehmens Dialog Consult werden es am Jahresende in Deutschland 88 Millionen Postpaid-Karten sein und damit fünf Prozent mehr als ein Jahr zuvor. Auch hier gibt es schon seit längerem einen Anstieg, 2023 waren es nur 72,2 Millionen gewesen.

Flatrates lassen Interesse an Prepaid sinken

„Der klassische Postpaid-Vertrag ist weiter auf dem Vormarsch“, sagt Marktforscher Andreas Walter von Dialog Consult. Er begründete die Entwicklung mit der „Reife des Marktes“. Die Verträge seien heute fair ausgestaltet und das Misstrauen der Kunden geringer als früher. „Die Kunden erleben keine bösen Überraschungen mehr, was die höhere Rechnung angeht – sie brauchen sowieso jeden Tag Datenübertragung.“ Ganz früher habe der Prepaid-Anteil bei mehr als 50 Prozent gelegen, inzwischen seien es nur noch 22,5 Prozent. Sei es früher im Wesentlichen um Anrufe gegangen, so gehe es inzwischen vor allem um Datenübertragung.

VATM-Präsidentin Valentina Daiber sagte, man lebe im „Zeitalter von Flatrates“ und der Kostenkontroll-Effekt sei nicht mehr nötig. Damit meinte sie, dass sich früher viele Menschen ganz bewusst für eine Prepaid-Karte entschieden, weil damit eine finanzielle Grenze gezogen war: Waren die 10 Euro abtelefoniert, brach die Verbindung ab. Bei Postpaid-Verträgen konnte es hingegen sein, dass dem Handynutzer die Kosten eines Anrufs erst im Nachhinein bewusst wurden und er mit der Monatsabrechnung gewissermaßen eine böse Überraschung erlebte.

(dahe)

Moderne Office-PCs erfordern keine großen Tower-Gehäuse mehr, sondern passen problemlos auf den Schreibtisch. Die meisten Mini-PCs haben jedoch eine fest eingelötete Mobil-CPU mit beschränkter Leistung und nur Platz für eine einzige SSD. Unser Bauvorschlag für einen 8-Watt-Mini ist trotz kompakter Abmessungen viel flexibler, denn er nimmt einen Desktop-Prozessor sowie zwei M.2- und zwei 2,5-Zoll-Datenträger auf.

Unser Fokus bei der Auswahl der Komponenten für den 8-Watt-Mini lag auf einem stabilen, leisen Betrieb sowie auf guter Ausstattung wie Thunderbolt 4 statt auf Leistung um jeden Preis. Der Computer benötigt bei ruhendem Desktop lediglich 8 Watt. Zudem haben wir darauf geachtet, dass der Bauvorschlag unter Windows 11 und Ubuntu 26.04 gleichermaßen reibungslos funktioniert.

Der effiziente Intel-Prozessor Core Ultra 5 225 liefert mit zehn Kernen genug Dampf für die meisten Alltagsaufgaben wie Text- und Fotobearbeitung. Alternativ taugt der 8-Watt-Mini aber auch als kompakter Heimserver. Angesichts der hohen Speicherpreise haben wir ihn in zwei RAM-Konfigurationen mit 1 × 16 GByte und 2 × 8 GByte Arbeitsspeicher durchgetestet, anhand der Sie die passende für sich heraussuchen können.

Das war die Leseprobe unseres heise-Plus-Artikels „8-Watt-Mini: Kompakten, sparsamen und leisen Mini-PC selbst bauen“.
Mit einem heise-Plus-Abo können Sie den ganzen Artikel lesen.