Ein klassisches Werk ist ein Buch, das die Leute loben, aber nie lesen. – Ernest Hemingway (1899 – 1961)
26 Java Native Interface (JNI)
Java kann nicht wirklich eine plattformunabhängige Programmiersprache sein – spätestens, wenn es an die tatsächlichen Ressourcen eines Rechners geht, müssen diese in Java eingebunden werden. Ein Sortierverfahren oder eine Datenstruktur ist wirklich plattformneutral, für das Bearbeiten von Dateien oder das Setzen von Punkten auf dem Bildschirm ist jedoch die jeweilige Architektur zuständig. Dazu ruft Java die nativen Methoden auf, die nicht in Java implementiert sind. Native Methoden sind in der API-Dokumentation nicht immer zu erkennen, aber ein Blick in den Quellcode verrät sie schnell.
|
public native int read() throws IOException; |
Beispiel 
26.1 Java Native Interface und Invocation-API 
Um diese Schnittstelle zwischen Java und konkreter Plattform kümmert sich das Java Native Interface (JNI). Mit Hilfe von JNI können aus der JVM heraus plattformspezifische Funktionen verwendet werden. Auch umgekehrt funktioniert dieser Weg: Ein C-Programm kann über die so genannte Invocation-API auf Java-Programme zugreifen. Mit diesen beiden Teilen kann eine Migration eines Altsystems nach Java realisiert werden. Mögliche Teile wie die grafische Benutzeroberfläche werden in Java implementiert und die übrigen Teile in der herkömmlichen Sprache belassen; ein Wrapper kapselt die Legacy-Systeme. Damit ist die alte Applikation lauffähig, und Schritt für Schritt können die Altlasten abgebaut werden. Ein Teil kann bestehen bleiben, wenn zum Beispiel eine gekaufte Bibliothek mit eingebunden werden soll oder Teile nicht unter Java implementiert werden können. Natürlich sind wir dann mit Java nicht mehr wirklich plattformunabhängig, da auch die native Bibliothek auf der neuen Plattform immer neu übersetzt werden muss.
Liegt Programmcode in einer anderen Programmiersprache als Java vor – wir gehen im Folgenden von C aus –, dann muss dieser zu einer dynamisch ladbaren Bibliothek gebunden werden. Diese Bibliothek implementiert die nativen Methoden, hält sich jedoch an spezielle Namenskonventionen. Das bedingt, dass es nicht möglich ist, beliebige Bibliotheken in Java einzubinden, die auf dem System schon vorhanden sind. Unter Windows kann zum Beispiel nicht einfach twain.dll verwendet werden, um Scanner anzusteuern.
Ist die dynamische Bibliothek vorhanden, muss sie noch in Java eingebunden werden. Dazu bindet die Methode System.loadLibrary() die Bibliothek zur Laufzeit in die JVM ein. Jeder Aufruf der nativen Funktion leitet die Laufzeitumgebung an die C-Funktion weiter.