Java JNI #

JNI (Java Native Interface) ist die Methode, um nicht-Java-Bibliothken in Java einzubinden.

Diese Seite hier soll (bisher) keine vollständige Beschreibung von JNI darstellen (das kann vielleicht auch die Wikipedia viel besser), sondern soll Anmerkungen sammeln, die den LUGern aufgefallen sind, bzw. die zu anderen Artikeln hier passen.

Benutzung von fertigen JNI-Bibliotheken #

Jede JNI-Anwendung besteht aus einer Java-Bibliothek (also normalen Klassen) und einem Native-Teil (unter Linux einer *.so)-Datei. Z.B. bei Java3D wird vorgeschlagen, daß man die Bibliothek in sein JRE hineininstalliert (Siehe JavaGrafik). Dies mag darauf hinweisen, daß es nach Meinung der Autoren eine gute Idee wäre, Java3D in das JRE aufzunehmen, ist jedoch, solange das Sun noch nicht getan hat, IMHO kein guter Stil.

Meiner Meinung nach gehören beide Bibliotheks-Dateien in das Java-Projekt. Die Java-Bibliothek wird eingebunden wie alle anderen Bibliotheken und für den Native-Teil muss der Library-Path erweitert werden, bevor man Java startet (das geht bestimmt auch eleganter, aber da habe ich mich bisher noch nicht mit beschäftigt).

JavaWebStart #

Ein kleines Problem ist die Benutzung von JNI-Bibliotheken unter JavaWebStart. JNI ist logischerweise ein gigantisches Sicherheitsloch. Deshalb müssen Programme, die JNI benutzen, immer vom Benutzer bestätigt werden. Andererseits sind heutige Windows-Benutzer natürlich eh gewohnt, auf alles zu klicken, d.h. kaum ein Benutzer wird davon abgeschreckt. Eine Ausnahme ist möglich, weil es möglich ist, die JNI-Bibliothek offiziell zu signieren. Dies hat Sun z.B. mit der JOGL-Bibliothek (siehe JavaGrafik) gemacht. Dieser Weg ist z.B. sinnvoll, wenn man geschlossene Benutzergruppen (oder ein Intranet) hat, denen man vorher eine eigene CA in den Browser installieren kann.

Installations-Beispiel für die EclipseIDE #

Ich nehme hier als Beispiel die JOGL-Bibliothek (siehe JavaGrafik). Ich lade von der JOGL-Downloadseite die aktuelle Version von JOGL herunter. Dazu gehören die Binaries, die Sourcen und das Javadoc-Paket. (Bei anderen Programmen kann es nötig sein, die Binaries und die Javadoc selber zu erzeugen, das soll hier aber nicht das Thema sein.) Diese entpacke ich nun an einer hierfür vorgesehenen Stelle in meinem Dateibaum (z.B. ~/Projekte/JavaLibrarySourcen/JOGL).

Grundsätzlich kann man in Eclipse externe Bilbiotheken (die also irgendwo im System installiert sind) oder interne (die Teil des Projektes sind und daher im Projektverzeichnis liegen) benutzen. Ich empfehle, immer alle Bibliotheken, die man benutzt, im Projekt abzulegen. Das erhöht die Portabilität ungemein und garantiert auch eine immer gleiche Version. Ich habe also in meinem nagelneuen Projekt ein Verzeichnis "lib" erstellt und dort aus der JOGL-Distribution alle "*.jar" und alle "*.so"-Dateien hineinkopiert. (Je nach Projektzielgruppe und Größe bleibt es zu überlegen, ob man hierfür ein eigenes Unterverzeichnis von lib anlegt und ob man die Windows-Bibliotheken mitkopiert) Die Sourcen und Javadocs sind meiner Meinung nach nur Hilfsdaten und werden von mir extern (d.h. in o.g. Verzeichnis und nicht im Projekt gehalten.

Nun rufe ich in den Projekt-Properties die Einstellungen zum "Java Build Path" auf. Hier benutze ich dann "Add JARs", um die JAR-Bibliotheken einzubinden. Bis hierhin läuft alles wie bei einer normalen Java-Bibliothek ab. Der Trick ist nun, daß man auf der "Libraries"-Registerkarte das kleine Dreieck vor "jogl.jar" anklickt, um es aufzuklappen und weitere Einstellungen vornehmen zu können. Hier wählt man "Java Native Library Location" und klickt rechts auf "Edit". Dann sucht man aus dem Workspace sein lib-Verzeichnis aus und fertig! Das gleiche empfehle ich für "Source Attachment" und "Javadoc Location", wobei ich dann "external Folder" statt "Workspace" benutze (Diese Einstellungen haben zwar nichts mit JNI zu tun, ich empfehle sie hier aber trotzdem, weil es genauso geht und genauso "versteckt" ist).