14.20 Grafikverarbeitung ohne grafische Oberfläche 

Im AWT sind viele Operationen fest mit einer konkreten grafischen Oberfläche verbunden und lassen sich nicht getrennt davon behandeln. Nahezu jeder Aufruf einer Graphics-Methode wie drawLine() ist nativ von einer Graphics-Unterklasse auf der Host-Plattform implementiert. So führt drawLine() direkt nach ein paar Umwandlungen auf eine Funktion auf der Plattform.

Am stärksten wird diese Einschränkung sichtbar, wenn ein Offscreen-Bild bearbeitet oder erstellt werden soll. Die Klassen dafür sind MemoryImageSource und PixelGrabber. Wenn wir nur ein Bild vom Dateisystem laden wollen (getImage() von Toolkit), dann dieses Bild in ein Integer-Feld umwandeln (MemoryImageSource), dieses dann über Filter laufen lassen und als Bitmap-Datei abspeichern wollen, hat das zunächst einmal nicht viel mit einer grafischen Oberfläche gemeinsam. Alle Operationen laufen im Hintergrund und ein Bildschirm ist nicht nötig. Diese Aufgaben sind ganz typisch für Server-Applikationen, etwa Servlets. Sie erzeugen zum Beispiel Grafiken für eine Serverstatistik und erstellen Börseninformationen. Leider sind aber alle Grafikoperationen, insbesondere das createImage(), für Hintergrundbilder von einer grafischen Benutzeroberfläche abhängig. Unter einem Windows-oder Macintosh-Server ist das zunächst kein Problem, da beide von Haus aus mit einer grafischen Oberfläche ausgestattet wurden. Im Serverbetrieb laufen jedoch sehr häufig Unix-Server, bei denen eine grafische Oberfläche nur Spielerei ist. Zudem öffnet ein X11-System unter Unix viele Sicherheitslöcher, die besser vermieden werden sollten. Erst seit der Version 1.4 hat Sun ebenfalls eine Lösung für Java angeboten, auf den X-Server zu verzichten. Andere Lösungen beschreiben die nächsten Absätze.

14.20.1 Xvfb-Server 

Eine Möglichkeit ist, auf dem Unix-Rechner einen speziellen X-Server zu installieren. Die gute Nachricht ist, dass es kein vollständiger X-Server sein muss, sondern, dass es unter X einen speziellen Server für die Shell gibt, den so genannten X-Virtual-Framebuffer-Server, kurz Xvfb-Server. Mit ihm können alle Grafikoperationen verwendet werden, da die Java-Implementierung dann den Bildschirmspeicher dieses virtuellen Servers nutzt. Um den virtuellen Server einzusetzen, muss Xvfb nur kompiliert werden; der Quellcode liegt unter htp://www.x.org/. Xvfb lässt sich als Dämon einsetzen und etwa mit folgender Anweisung aktivieren:

# /usr/X11R6/bin/Xvfb :1 -screen 0 1152x900x8 2>>/var/adm/Xvfb.log &

Für das AWT muss die DISPLAY-Variable noch gesetzt werden.

DISPLAY='hostname':1.0

14.20.2 Pure Java AWT Toolkit (PJA) 

Eine andere Lösung für das Problem ist das Pure Java AWT Toolkit (kurz PJA). Diese hundertprozentige Java-Implementierung ist eine Unterklasse von Graphics und implementiert die Methoden ohne nativen Code. So kann auf einen speziellen Server verzichtet werden, es lassen sich Ressourcen schonen und dennoch Bilder im Hintergrund berechnen. Die Installation ist dabei nicht kompliziert, und da die Bibliothek unter der GNU General Public Licence liegt, lassen sich die Quellen zur Not auch modifizieren. Das Ersatz-AWT wird dabei einfach über die Umgebungsvariable java.awt eingeführt. Der Verweis zeigt auf com.eteks.awt.PJAToolkit, und dann sind keine Modifikationen an den Programmen mehr erforderlich. Die grafische Klasse nutzt nun nicht mehr das native Standard-AWT, sondern PJA.

Das PJAToolkit rendert in einigen Fällen die grafischen Primitiven anders als es die Java-API-Dokumentation beschreibt. So erläutert die Hilfe von Eteks etwa, dass unter MacOS SansSerif anders dargestellt wird und die Ellispsen etwas anders aussehen könnten, da sie mit Bresenham gezeichnet werden.

Die Bibliothek kann mit Beispielprogrammen (unter anderem GIF generieren, Font-Auszüge erstellen, Servlet erstellt Diagramm), FAQ, Quellcode, Jar-Archiven unter http://www.eteks.com/pja/en/ bezogen werden. Im Download befindet sich auch eine Batch-Datei, die zeigt, wie die Variable gesetzt wird und wie die beiden Jar-Dateien heißen, die eingebunden werden müssen. PJA steht unter der GNU General Public License und der Quellcode kann wie immer eingesehen und modifiziert werden.