In den letzten Tagen sind zwei fachlich fundierte Artikel von Entwicklern herausgekommen, die sich mit dem "Krieg des Tages" befassen. Da in der binären Welt der Computer man sich ja noch nie auf ein Bestes einigen konnte, besteht in der Java-GUI-Gemeinde nun der Konflikt zwischen AWT/Swing auf der einen und SWT/JFace auf der anderen.
In seinem mit dem schönen Titel "SWT Happens" bedachten Text argumentiert "Mr. Ed", dass Eclipse mit seinem Ansatz, die jeweils nativen GUI-Elemente (Widgets) der zugrundeliegenden Plattform zu verwenden, sich einen Wartungsalbtraum aufgebürdet hat. Das SWT muss die Ansteuerung der jeweiligen Fenster-Plattform (Windows, X-Window/GTK, Motif, Mac OS X) komplett plattform-abhängig implementieren. Nach oben, im SWT selbst, stehen dann plattform-übergreifend nur jene GUI-Elemente zur Verfügung, die auf allen Plattformen verfügbar sind. Allerdings mit Ausnahmen: Eine Baumansicht, wie die Ordnerstruktur im linken Fenster eines Windows-Explorers, steht auf vielen Plattformen nicht nativ zur Verfügung. Die Anwendungsbereiche für diese Darstellung sind aber so viele und die Anwender an diese Darstellungsweise so gewöhnt, dass niemand darauf verzichten möchte. Daher werden solche Widgets in Eclipse plattform-übergreifend programmiert.
Bei Eclipse/SWT ist das die Ausnahme. Um solchen Dingen generell aus dem Weg zu gehen und Anwendungen sozusagen die GUI-Maximalausprägung bieten zu können, greift Sun's AWT/Swing garnicht auf native Elemente zurück, sondern läßt sich nur eine weiße Leinwand bereitstellen (die gibt's überall) und malt alle Widgets selbst.
Die Kritik von "Mr. Ed" bezieht sich hauptsächlich darauf, dass der SWT-Code nicht frei von Fehlern ist, und wegen der Unterstützung so divergenter Plattformen wie Windows und Motif auch gar nicht sein kann. Er konstatiert, dass seine Produktivität wegen dieser Fehlersuche unter SWT deutlich gelitten hat.
Die Gegenseite in Form von Amin Ahmad's Swing vs. SWT? geht nicht auf die Low-Level-Aspekte ein, also die Schwierigkeit, ein GUI-Toolkit über mehrere Plattformen hinweg konsistent und in den wesentlichen Funktionen fehlerfrei zu halten. Stattdessen hebt Ahamd auf den Produktivitätsaspekt ab:
Sein Argument ist, dass man SWT/JFace als Basis-Bibliotheken nicht mit AWT/Swing vergleichen darf, sondern die Eclipse-Plattform und ihre Plug-Ins in den Vergleich einbeziehen muss, weil - so Ahmad - in der Eclipse-Plattform schon viele der Probleme umgangen oder gelöst sind, die in der SWT-Infrastruktur existieren. Entwickler sollten sich von den Low-Level-Aspekten fernhalten und auf dem Funktionsangebot von Eclipse aufsetzen.
Auch "Mr. Ed" nimmt Eclipse in seine Betrachtung auf, kommt allerdings zu einem anderen Ergebnis als Mr. Ahmad. Er sagt, dass er keine Probleme sieht, Eclipse-ähnliche Projekte auf der Eclipse-Grundlage abzuwickeln. Je weiter aber die Ziel-Applikation sich von der Grundidee hinter Eclipse, einer Entwicklungsumgebung, unterscheidet, desto weniger Unterstützung findet man in Plattform und Plug-Ins. Und dann treten die Probleme in der Infrastruktur wieder mehr zu Tage.
Wer gerade die Umsetzung einer Java-GUI-Applikation plant und noch nicht weiß, ob er auf Eclipse oder Swing aufsetzen soll, wird von der Lektüre dieser Artikel, der darin genannten Referenzen und zum Teil auch den Kommentaren der Leser, nützliche Einsichten gewinnen und Hinweise finden, welche Funktionen seiner Anwendung er besser mit Proof-of-Concepts vorab absichert.
Keine Kommentare:
Kommentar veröffentlichen