16.11 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 einigen 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), dieses Bild dann in ein Integer-Feld umwandeln (MemoryImageSource), anschließend über Filter laufen lassen und als Bitmap-Datei abspeichern, so hat dies zunächst 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 Server-Statistik 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 Server-Betrieb laufen jedoch sehr häufig Unix-Server, bei denen eine grafische Oberfläche nur Spielerei ist. Zudem öffnet ein X11-System unter Unix einige 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.
16.11.1 Xvfb-Server 
Eine Möglichkeit besteht darin, auf dem Unix-Rechner einen speziellen X-Server zu installieren. Die gute Nachricht lautet, 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, weil die Java-Implementierung dann den Bildschirmspeicher dieses virtuellen Servers nutzt. Um den virtuellen Server einzusetzen, muss Xvfb nur compiliert werden; der Quellcode liegt unter http://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 noch die DISPLAY-Variable gesetzt werden:
DISPLAY='hostname':1.0
16.11.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, Ressourcen lassen sich schonen, und dennoch können Bilder im Hintergrund berechnet werden. Die Installation ist nicht kompliziert, und weil 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. Wenn der Verweis auf com.eteks.awt.PJAToolkit zeigt, 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 Ellipsen etwas anders aussehen könnten, weil sie mit Bresenham gezeichnet werden.
Die Bibliothek kann mit Beispielprogrammen (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.