Java Native Interface

Für das plattformunabhängige Layout bereiten AWT und Swing dem Entwickler die gleiche Problem: Er muss sein Programm auf allen Zielplattformen testen. Bei SWT kommt hinzu, dass es das Java Native Interface [9] verwendet. Mit JNI erreicht Javas Idee der Plattformunabhängigkeit dann auch ihr Ende: Das Interface macht Java-Anwendungen die Routinen vorhandener Binärbibliotheken zugänglich. Dazu muss die Java-Klasse die Bibliothek selbst laden, entweder eine Shared Library bei Linux und Unix oder eine DLL unter Windows.

Wer ein JNI-nutzendes Programm für mehrere Plattformen bereitstellen will, sollte die Shared Libraries am besten selbst einpacken – auch wenn es Standardbibliotheken sind –, um Versionskonflikte zu vermeiden. SWT, das wie erwähnt JNI verwendet, liefert die entsprechenden Binärbibliotheken mit. Beim Paketieren der eigenen Anwendung, baut man entweder einzelne Pakete für die unterschiedlichen Plattformen oder packt alle Versionen ein.

Eine interessante Alternative zu JNI ist Java Native Access (JNA, Homepage und Download unter [10]). Statt die Shared Library hinzuzuladen, stellt JNA nur eine kleine Klasse bereit, die generische Bibliotheken lädt, den Rest erledigt der Entwickler in reinem Java. Im Paket finden sich Interfaces für Linux, Free BSD und Windows für 32 und 64 Bit.

Die Matrix

Java-Kompatibilität entfaltet sich zu einem zweidimensionalen Problem: Auf der einen Achse kann man die Versionen – beginnend mit 1.0 – bis zum gerade erschienenen Java 7 [3] auftragen. Auf der zweiten Achse stehen die JVMs verschiedener Hersteller, die wichtigsten sicherlich Oracle, IBM und Open JDK. Hinzu kommt Android mit der Dalvik Engine, die funktional etwas deutlich anderes ist. Der Entwickler, der seinen Code nur einmal schreiben und eine mobile Version seiner Software unters Volk bringen will, muss alle Besonderheiten dieser Plattform beachten, nicht nur beim sowieso anders gearteten GUI.

Übersetzter Java-Bytecode ist aufwärtskompatibel, Oracle gibt sich mit ausgiebigen Kompatibilitätstests große Mühe, dass die mitgelieferten Runtime-Bibliotheken stabil bleiben. Lediglich die Hersteller von 3rd-Party-Bibliotheken ändern gelegentlich APIs, üblicherweise aber erst, nachdem sie ihre Absicht schon in der Vorversion per Deprecated-Markierung angekündigt haben. Das bedeutet, dass eine mit dem Compiler aus Java 1.0 übersetzte Klasse auch unter Java 7 ausführbar bleibt. In der anderen Richtung gilt dies aber nicht!

Entwickler portabler Programme sollten sich daher nicht am neuesten Stand der Technik orientieren. Gerade wer Software übers Internet verteilt, sollte seine Klassen kompatibel zur vorletzen Version übersetzen. Beim Übersetzen mit Javac sorgt die Option »-target Release« dafür, »-source Release« veranlasst den Compiler auch dazu, so zu kompilieren, als wäre er die angegebene Version.