WikiDer > Native Java-Schnittstelle

Java Native Interface
Java-Plattformportal

Das Native Java-Schnittstelle (JNI) ist ein API innerhalb der Java-Plattform. Das JNI ist eine Schnittstelle zwischen Programme in Java geschrieben und Programme in der Unterrichtssprache der Hardware- auf dem auch die Java virtuelle Maschine Laufen – sog. gebürtig Programme.

Technische Ausführung

Die JNI definiert a Schnittstelle bidirektional zwischen der JVM und externem Code.

Die erste Richtung ist von innerhalb der JVM zum Code außerhalb der JVM und wieder zurück. Diese Verwendung des JNI besteht darin, dass innerhalb eines (oder mehrerer) Klasse(n) eine oder mehrere Methoden sind definiert als gebürtig gekennzeichnet sein. Eine native Methode innerhalb der JVM ist implizit abstrakt – es gibt keine Implementierung in der JVM. Stattdessen wird eine Implementierung in einem nativen Programm angegeben, das in a kompiliert wird dynamische Bibliothek für die Hardwareplattform unter der JVM. Diese Bibliothek wird von der JVM auf Anforderung des Programms, das die Bibliothek verwenden möchte, in den Speicher geladen. Das Programm zeigt dies der JVM durch einen speziellen Befehl (java.lang.Runtime.loadLibrary()), die innerhalb eines statischen Blocks angegeben und somit beim Laden der betreffenden Klasse ausgeführt wird.

Die andere Richtung führt von einem nativen Programm zur JVM und zurück. In diesem Fall verwendet das native Programm die JNI, um eine Instanz der JVM zu laden und zu starten, und verwendet dann diese JVM-Instanz, um ein Java-Programm auszuführen.

In beiden Fällen stellt das JNI eine Brücke zwischen der JVM und nativen Programmen bereit, die eine gegenseitige Codeausführung ermöglicht. Diese Brücke besteht hauptsächlich aus Methoden, um eine Klasse oder Methode im Speicherbereich der JVM aufzurufen und Code ausführen zu lassen, aber auch aus einer Zuordnung zwischen den in der JVM definierten primitiven Typen und den in der JVM vorhandenen primitiven Typen. Programmiersprache in dem das native Programm geschrieben ist. Über diese Brücke kann ein natives Programm Code innerhalb der JVM aufrufen oder das Ergebnis einer Berechnung an eine JVM liefern. Für die Kommunikation in die andere Richtung bedient die JVM die Mechanismen des JNI und die im Java-Programm definierten nativen Methoden werden wie "normale" Methoden angesprochen.

Nativer Code wird normalerweise in einer anderen Programmiersprache als Java geschrieben. Für die sehr beliebten Sprachen wie C und C es gibt Standardtools wie javah die den Programmierer bei der Nutzung des JNI unterstützen, indem sie Teile nativen Codes generieren, wonach nur noch die eigentliche Implementierung abgeschlossen werden muss. Das Fehlen solcher Tools für andere Sprachen bedeutet jedoch nicht, dass sich das JNI ausschließlich auf die „unterstützten“ Sprachen konzentriert: Es kann jede Sprache verwendet werden, die native Programme generieren und auf dynamische Bibliotheken zugreifen kann.

Vor-und Nachteile

Das JNI ist von Anfang an Teil der Java-Plattform. Die JNI wurde eingeführt, um Java-Programmen Zugriff auf Einrichtungen zu geben, auf die die JVM und vorhandene Java-Klassen keinen direkten Zugriff bieten.

Durch das JNI ist es möglich, die Fähigkeiten eines Java-Programms auf die Fähigkeiten des gesamten Computers auszudehnen, einschließlich beispielsweise des Zugriffs auf Peripheriegeräte, die nicht direkt von der JVM und der Klassenbibliothek unterstützt werden. Außerdem ist es mit dem JNI möglich, eine JVM in ein natives Programm einzubetten und alle Möglichkeiten der Java-Klassenbibliothek zu nutzen oder schnell ein kleines Java-Programm auszuführen (indem Sie eine JVM starten, in der nicht alle Klassen aus der Klassenbibliothek vorgeladen werden). Auch das JNI wurde in den Anfangstagen von Java als geeignete Methode für geschwindigkeitskritische Algorithmen durch Nutzung des Geschwindigkeitsvorteils nativer Programme auf der zugrunde liegenden Hardware. Dieser letzte Vorteil ist mit der Ankunft von Just-in-Time-Compiler kompilieren für Java jedoch weitgehend verschwunden.

Heutzutage wird das JNI immer weniger verwendet und es wird zunehmend davon abgeraten, es sei denn, es gibt wirklich keine andere Option. Entwicklungen im Bereich der JVMs (Just-in-Time-Compiler und HotSpot-Compiler) haben den Geschwindigkeitsunterschied eines laufenden Java-Programms im Vergleich zu einem ähnlichen Programm in nativem Code verringert. Im Gegensatz dazu bedeutet die Verwendung des JNI, dass ein Teil des Programms in Bezug auf die Speichernutzung nicht von der JVM kontrolliert wird, was zu Speicherlecks führen kann. Darüber hinaus ist es ziemlich einfach, nativen Code (insbesondere wenn er in C oder C geschrieben ist) zu verwenden, um den Speicherplatz der JVM zu verschmutzen und die gesamte JVM zum Absturz zu bringen. Dies ist ein Problem für ein einfaches Programm auf einer einfachen JVM, aber eine sehr komplexe Installation wie eine JVM innerhalb eines Anwendungsserver ist diesbezüglich besonders empfindlich – ein Argument, das die Verwendung von JNI im Kontext von a J2EE-Anwendung entmutigt.
Zudem bindet die Verwendung des JNI ein Java-Programm nicht nur an die JVM (die natürliche Umgebung eines Java-Programms), sondern auch an die zugrundeliegende Hardware und oft auch an die Betriebssystem. Dies bedeutet, dass ein Java-Programm plötzlich nicht mehr von JVM auf JVM übertragbar ist. Es kann auch bedeuten, dass ein Java-Programm ein Update des Betriebssystems auf derselben Hardware nicht übersteht, wenn die dynamischen Bibliotheken das Format ändern.

Die oben genannten Nachteile sowie die Tatsache, dass Java-Programme immer direkter über die JVM auf gängige Hardware zugreifen können, haben dazu geführt, dass das JNI in letzter Zeit immer weniger verwendet wird. Die beiden Bereiche, in denen das JNI heute hauptsächlich eingesetzt wird, sind die Entwicklung spezifischer Software für eine bestimmte Zielgruppe auf einer bestimmten Maschine mit besonderen Hardwareanforderungen (z. B. ungewöhnliche Hardware) und in Dolmetscher für Skriptsprachen, die die Verwendung von Java-Klassen in Skripten ermöglichen möchten. Für letztere Kategorie wird an einer Erweiterung der Java-Plattform gearbeitet, um die Interaktion zwischen JVM und Interpretern zu verbessern, die sogenannte JSR-223.