22.6Einfache Anbindung von existierenden Bibliotheken 
Die Arbeit mit JNI ist nicht besonders komfortabel, sodass im Laufe der Zeit einige Vereinfachungen entstanden sind. Auf der einen Seite stehen Quellcodegeneratoren, auf der anderen Seite sehr dynamische Lösungen.
22.6.1JNA (Java Native Access)
Eine Bibliothek zum Ansprechen dynamischer Bibliotheken ohne JNI-Kontakt und damit ohne C(++)-Compiler ist JNA (Java Native Access). Beheimatet ist das Projekt unter https://github.com/twall/jna/, und es steht unter der Lizenzform LGPL. JNA benötigt nur das Archiv jna.jar im Klassenpfad und geht dann fast von selbst zu dynamischen Bibliotheken. Verschiedene Plattformen werden unterstützt, dazu zählen Windows, Linux und Mac OS X.
Vor dem Zugriff müssen allerdings Java-Schnittstellen als typisierte Versionen der nativen Funktionen deklariert werden, damit auch die Datentypen von der Java-Seite automatisch auf Datentypen der nativen Seite gemappt werden können. Die Dokumentation unter https://github.com/twall/jna/blob/master/www/GettingStarted.md zeigt ein Beispiel (hier etwas gekürzt):
public class HelloWorld {
public interface CLibrary extends Library {
CLibrary INSTANCE = (CLibrary) Native.loadLibrary( Platform.isWindows() ? ¿ "msvcrt" : "c", CLibrary.class );
void printf( String format, Object... args );
}
public static void main( String[] args ) {
CLibrary.INSTANCE.printf( "Hello, World\n" );
for ( int i = 0; i < args.length; i++ )
CLibrary.INSTANCE.printf( "Argument %d: %s\n", i, args[ i ] );
}
}
Die Übertragung der Funktionen von der C-Seite in Java-Schnittstellen – wie CLibrary in dem Beispiel – kann auch mit JNAerator (http://code.google.com/p/jnaerator/) automatisiert werden.
22.6.2BridJ
BridJ (https://code.google.com/p/bridj/) verfolgt den gleichen Ansatz wie JNA, kann also auch aus Java heraus nativen Code von C(++) und auch Objective-C ansprechen. Nur steht es als quelloffene Bibliothek nicht unter der LGPL-, sondern unter der BSD/Apache-Lizenz. Zudem ist es aktueller, nutzt Generics und diverse Tricks, um noch performantere native Aufrufe zu realisieren. Auch kann es besser mit den Eigenschaften von C++ umgehen, wie virtuellen Methodenaufrufen, kann Vererbung und Templates »verstehen«. Regelmäßige Updates gibt es für die Systeme Windows (x86, x64), Linux (x86, x64, arm32), Mac OS X (x86, x64, PPC), Solaris 10 (x86, bald x64 und SPARC), Android 3.0 (ARMv5) und experimentell auf jailbroken iOS iPhones (ARM). Ob das ältere JNA oder BridJ besser ist, muss im Einzelfall evaluiert werden. JNAerator unterstützt ebenfalls BidJ zur Generierung der typisierten Schnittstellen und Übergabeobjekten.
22.6.3Generieren von JNI-Wrappern aus C++-Klassen und C-Headern
cxxwrap (http://cxxwrap.sourceforge.net/) liest Header-Dateien von C++ ein und generiert automatisch für die Klassen Stellvertreter auf der Java-Seite sowie Delegates in JNI, die auf die tatsächliche Implementierung weiterleiten. Aus den Beschreibungen der Header-Dateien nimmt cxxwrap nicht nur die Klassen mit Methoden, sondern auch die Konstanten. Auch versucht cxxwrap, so gut wie möglich die Parametertypen zu übersetzen, etwa char unsigned char in byte, und Pointer auf primitive Zellen in Arrays umzusetzen. Die Konstruktoren, Destruktoren und Methoden werden von der Java-Seite auf die C++-Seite weitergeleitet. Das Projekt wurde schon lange nicht mehr gepflegt, aber da sich die JNI-API auch nicht groß verändert hat, kann cxxwarp ein erster Start sein. Eine aktuellere Alternative ist gluegen (http://java.net/projects/gluegen/); gluegen wird verwendet, um die Open GL-Schnittstellen nach Java zu bringen. Dazu liest es die C-Header-Dateien und macht so die Methoden für Java-Programme zugänglich.
Ein weiterer Generator ist SWIG (Simplified Wrapper and Interface Generator) unter http://www.swig.org/. Mit einer zu schreibenden Interface-Datei generiert SWIG den JNI-Code für den Zugriff auf existierende C(++)-Programme. Das Projekt ist sehr aktiv.
22.6.4COM-Schnittstellen anzapfen
Sind die nativen Methoden über COM zugänglich, ermöglichen die Bibliotheken Jawin (http://jawinproject.sourceforge.net/) und com4j (https://github.com/kohsuke/com4j) mit einer kleinen nativen Bibliothek einfachen Zugriff auf diese Ressourcen; besonders praktisch ist das für MS Office, da es sich so praktisch fernsteuern lässt. com4j ist besonders nützlich, denn ein Generator erzeugt Java-Wrapper, sodass typsicheres Arbeiten möglich ist. Damit Programme mit com4j übersetzt und zum Laufen gebracht werden können, muss sich com4j.jar im Klassenpfad befinden und com4j.dll im Suchpfad für externe native Bibliotheken stehen. Ein Beispiel für Word liegt der Distribution bei. Jawin wurde schon länger nicht mehr aktualisiert, tut jedoch seine Dienste. com4j ist aktueller, aber auch seit zwei Jahren ohne Update.
