Linux wird auf dem Desktop salonfähig, von Java ist dies leider nicht zu behaupten, zu gründlich wurde der Ruf schon vor Jahren ruiniert. Mit den Java-Language-Bindings ist aber eine performante und saubere Integration in das K Desktop Environment möglich.
Java-Anwendungen auf dem Client gelten immer noch als wenig performant, auch wenn dieses Argument in Zeiten von Einsteiger-PCs jenseits von 2 GHz und 256 MByte Speicher immer weniger sticht. Aber: Noch so viel Performance ändert gar nichts an dem zweiten Kritikpunkt - dem Look & Feel der Anwendungen. Suns Widgetset AWT war bei Anwendern und Programmierern gleichermaßen unbeliebt. Unter Linux zeigte es sich im altbackenen Motif-Design. Mit Java 1.1 und Swing (seit 1.2 integriert) besserte sich die Situation zumindest für den Programmierer. Er kann jetzt aus einem umfassenden Satz an Widgets wählen. So gibt es kaum einen Wunsch, der unerfüllt bleibt.
Swing bietet darüber hinaus noch ein zur Laufzeit austauschbares Look & Feel. Letztlich bleiben aber Swing-Anwendungen auf Linux-Seite Fremdkörper für die verbreiteten Desktopsysteme. Ob dies tatsächlich die Usability einschränkt, sei dahingestellt. Ein »Datei | Öffnen«-Dialog im Dateimenü oben rechts wird erfahrene Anwender kaum überraschen, kann unbedarfte Nutzer aber durchaus verunsichern.
Neben Usability und Ästhetik spielen für integrierte Desktop-Umgebungen auch andere Gesichtspunkte eine Rolle, so zum Beispiel die einheitliche Ablage von Konfigurationen. Deshalb ist eine engere Einbindung von Java-Anwendungen in den Linux-Desktop sehr zu begrüßen. Ein Artikel im Linux-Magazin[1] zeigte bereits vor längerer Zeit die Integration von Java in Gnome[2] und diese Coffee-Shop-Ausgabe demonstriert die Verzahnung mit dem KDE.
Um Java-GUI-Anwendungen im KDE-Look & Feel schreiben zu können, müssen die Java-Bindings installiert sein. Für SuSE gibt es zum Beispiel fertige Binary-RPMS (»kdebindings3-java-3.1.3«). In anderen Fällen hilft der Weg über das KDE-CVS. Die Anlaufstelle für die Java-Bindings ist[2], von dort gibt es auch einen Link zum CVS.
Nur vier Dateien sind erforderlich, um die Integration zu vollbringen: zwei Jar-Dateien für Kompilation und Laufzeit (»qtjava.jar« und »koala.jar«) sowie zwei dynamische Bibliotheken (»libqtjava.so« und »libkdejava.so«). Die Jar-Dateien landen zumindest bei SuSE unter »/opt/kde3/lib/java«, die dynamischen Bibliotheken dagegen erwartungsgemäß unter »/opt/kde3/lib/«.
Die Konfiguration besteht darin, die Jar-Dateien während der Entwicklung und Ausführung in den »CLASSPATH« aufzunehmen. Die dynamischen Bibliotheken sind nur zur Ausführungszeit notwendig, sie müssen im »java.library.path« liegen. Ersteres erfolgt in der IDE der Wahl beziehungsweise im Make- oder Build-File. Zum Ausprobieren hat sich auch das Skript aus Listing 1 bewährt. Es enthält eine Shell-Funktion, die alle Jars aus allen als Argumente übergebenen Verzeichnissen dem »CLASSPATH« hinzufügt. Das Skript lädt man über den Punkt-Befehl (»source«) in die aktuelle Shell, anschließend wird die Funktion aufgerufen:
addjars.inc addjars /opt/kde3/lib/java
Die dynamischen Bibliotheken findet der Java-Interpreter, wenn man das Suchverzeichnis mittels
java -Djava.library.path=/opt/kde3/lib ...
angibt. Mehr ist zur Installation und Konfiguration nicht nötig. Allerdings: Ohne Dokumentation geht nichts - und hier ist man völlig auf den Quellcode angewiesen. Im Prinzip genügt es zwar, sich die API-Referenz über Standardmethoden (»javadoc«) selbst zu erzeugen, aber eine Metadokumentation bleibt wünschenswert.
Alle Rezensionen aus dem Linux-Magazin
Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...
