JEP Adventskalender #16

JEP 370: Foreign-Memory Access API (Incubator)

Dominik Mohilo

A JEP a day keeps the Christmas blues away! Frei nach diesem Motto stellen wir euch in diesem Jahr zwischen den Jahren sämtliche JEPs der kommenden Java-Version vor. Ganze 16 JEPs haben es in Java 14 geschafft, deutlich mehr als es in den vorigen Versionen Java 12 und Java 13 vertreten waren (8 bzw. 5 JEPs).

Das Jahr 2019 brachte uns Java 12 und Java 13, allerdings waren diese Versionen unserer liebsten Programmiersprache nicht besonders umfangreich, was neue Features betrifft. Größe ist nicht immer der entscheidende Faktor, dennoch waren JDK 12 und 13 nicht vergleichbar mit etwa Java 8 oder Java 9. Dies liegt natürlich auch am neuen Releasezyklus und muss nicht zwangsläufig etwas Negatives sein – im Gegenteil: steter und gleichmäßiger Fortschritt ist einem großen Klotz an neuen Funktionen (und Problemen) von Zeit zu Zeit durchaus vorzuziehen.

Java 14 wird nun aller Voraussicht nach ein wenig „dicker“. Grund genug für uns hier bei JAXenter, über die enthaltenen JEPs zu berichten. Zudem steht Weihnachten vor der Tür! Santa Duke is coming to town – Schauen wir uns einmal an, was er in seinem Geschenkesack hat…

Lesen Sie auch: Java 14: Das JDK ist in der Rampdown-Phase

JEP 370: Foreign-Memory Access API (Incubator)

Es gibt tonnenweise Java-Bibliotheken und auch -Anwendungen, die auf fremden Speicher zugreifen. Prominente Beispiele sind Ignite, mapDB, memchaced oder Nettys ByteBuf API. Dennoch stellt das Java API selbst keine gute Möglichkeit hierfür zur Verfügung – und das obwohl dadurch Kosten in Sachen Garbage Collection (besonders bei der Verwaltung großen Caches) gespart und Speicher über mehrere Prozesse hinweg geteilt werden kann. Auch das Serialisieren und Deserialisieren von Speicherinhalten via Mappings von Dateien in den Speichern wird durch den Zugriff auf fremden Speicher möglich (etwa via mmap).

Mit JEP 370 soll ein passendes Java API ins JDK implementiert werden, mit dem Java-Anwendungen sicher und effizient auf fremden Speicher zugreifen lässt, der außerhalb des Java Heaps angesiedelt ist. Wichtig sind die drei Prämissen: Allgemeingültigkeit, Sicherheit und Determinismus.

Ersteres bedeutet, dass ein einziges API in Verbindung mit unterschiedlichen fremden Speichern arbeiten sollte (gemeint sind nativer Speicher, persistenter Speicher etc.). Die Sicherheit der JVM ist das höchste Gut, daher sollte das API nicht dazu fähig sein, diese zu unterwandern – völlig egal, welcher Speicher zum Einsatz kommt. Zudem (Determinismus) sollte die Freigabe von Speicher explizit im Quelltext erfolgen.

Dieses JEP wurde im Zuge des Project Panama entwickelt und stellt eine klare Alternative zur Verwendung von existierenden APIs wie ByteBuffer, Unsafe oder JNI dar. Natürlich hilft die Implementierung bei der Erreichung der generellen Maxime des Projektes: der Unterstützung von nativer Interoperabilität von Java.

Java Whitepaper

Gratis-Dossier: Java 2020 – State of the Art

GraalVM, Spring Boot 2.2, Kubernetes, Domain-driven Design & Machine Learning sind einige der Themen, die Sie in unserem brandneuen Dossier 2020 wiederfinden werden!

Geschrieben von
Dominik Mohilo
Dominik Mohilo
Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.
Kommentare

Hinterlasse einen Kommentar

avatar
4000
  Subscribe  
Benachrichtige mich zu: