Vor dem Hintergrund der laufenden Debatte über die Zukunft von Swing sprach die JAXenter-Redaktion mit Danny Coward, Chefarchitekt von Sun's Client Software und verantwortlich für die technische Ausrichtung von Java SE und ME sowie JavaFX.

In der Renaissance der Rich Clients ist es verwunderlich, dass ausgerechnet Swing so lange auf Eis gelegen hat. Was sind die Gründe dafür?

Coward: Tatsächlich hat sich eine Veränderung vollzogen: Wir stecken mehr Arbeit in unsere Rich-Client-Technologien, die Swing beinhalten. Im Java SE 6u10 Release haben wir schon einige große Verbesserungen einfließen lassen, um die von Swing genutzte Runtime schneller zu machen. Außerdem planen wir ein großes neues API für Swing: ein Application Framework, das im JCP im JSR-295 erarbeitet wird. Zusätzlich verfügen wir noch über viele Community-Beiträge wie beispielsweise das XRender Projekt, Date Picker und CSS-Styling-Funktionalität, die wir in JDK 7 einbauen möchten. Wenn man das alles zusammenzählt, hat man mehr API-Features als in Java SE 6. Ich glaube, dass der Fokus auf JavaFX manchmal einen falschen Eindruck hinterlässt, denn wir arbeiten weiter an Swing für JDK 7.

Sie schreiben in Ihrem Blog, dass Swing 2.0 nicht JavaFX- sondern Java-basiert sein sollte. Was bedeutet das konkret bzw. was bedeutet "JavaFX-Basierung" überhaupt?

Coward: Wir haben ein sehr erfolgreiches GUI-Programmiermodell, das auf Java und den Swing APIs basiert. Es eignet sich hervorragend für eher traditionelle GUIs wie Limewire. Aber die Wahrheit ist doch: Für die nächste Welle der web-basierten Rich-Client-Applikationen, die in Stil und Kreativität stark von Web-Applikationen beeinflusst wurden, haben die Developer-Designer nicht Java und Swing gewählt, um diese Applikationen zu bauen. Zusätzlich zu Swing wollten wir daher einen neuen Weg finden, um die Untermauerung von Swing darzustellen, und zwar in Form des graphischen Potenzials und der skalierbaren Java-Runtime, genau für diese neue Welle an Developer-Designern. Deshalb haben wir nun zusätzlich zu Swing auch JavaFX, das unserer Meinung nach für diese Zielgruppe sehr attraktiv ist.

Wird Swing neben JavaFX nicht allmählich zur Legacy-Technologie werden?

Coward: Nein, und zwar aus mehreren Gründen: Applikationen wie der PC iTunes Client zeigen uns, dass es immer noch eine hohe Nachfrage für traditionelle GUI-Applikationen gibt, die auf Desktop-zentrierten GUI-Toolkits basieren. Um solche Applikationen zu bauen, brauchen wir Swing. Der zweite Punkt betrifft wieder die Untermauerung von Swing: Grafiken und Desktop-Runtime müssen noch flinker werden, um sowohl Swing als auch JavaFX zu nutzen, sprich schnellerer Download, Upgrade und Ausführung der Applikationen. Und drittens: JavaFX (und andere neue GUI-Frameworks wie das Groovy-basierte Griffon) hängt von vielen Swing-Komponenten ab – schauen Sie sich beispielsweise das javafx.ext.swing-Package an, das von einigen eher bekannten Swing-Komponenten als Teil von JavaFX 1.1 abhängt.

Das heißt: Die Rolle von Swing ändert sich zwar, aber Swing hat meiner Meinung nach eine glänzende Zukunft vor sich.

Wie wird die Beziehung zwischen Swing und JavaFX künftig aussehen?

Coward: JavaFX und Swing teilen sich eine gemeinsame zugrunde liegende Runtime und graphische Schicht. JavaFX beruht auch in Bezug auf einige desktop-zentrierte Kern-Features wie UI-Komponenten auf Swing. JavaFX und Swing unterscheiden sich dahingehend, dass Swing das Toolkit der Wahl für traditionelle Desktop-zentrierte GUI-Applikationen ist, die von Java-Entwicklern gebaut werden, während unserer Meinung nach JavaFX eine attraktive Technologie für Developer-Designer sein wird, die eine stärkere künstlerische Neigung und weniger eine formale Ausbildung in Programmiersprachen haben.

Swing hat sich merkwürdigerweise nie von den alten Vorurteilen, es sei hässlich und langsam, befreien können, obgleich es genügend Beispiele gibt, die das Gegenteil beweisen. Was ist Ihrer Meinung nach der Grund dafür?

Coward: Ich denke, populäre Technologien haben immer auch Kritiker. In der Anfangszeit war Swing langsam. Obwohl dieses Vorurteil durch die Verbesserungen an Swing überholt ist, halten einige Leute wohl noch an den alten Einstellungen fest. Dabei haben wir Fortschritte in der JVM und Optimierungen in den Bibliotheken vollbracht, um die graphische Beschleunigung zu nutzen wo wir können (beispielsweise Direct3D auf Windows). Das Attribut "hässlich" habe ich schon lange nicht mehr gehört. Immerhin haben wir mit dem Java SE 6u10 Release ein schönes neues Look&Feel für Swing namens Nimbus veröffentlicht. Es nutzt skalierbare Vektor-Grafiken zum Rendern von Visuals, so dass es in jeder Auflösung gut aussieht.

Rich Clients werden heute häufig mit Eclipse RCP gebaut, das ja SWT- und nicht Swing-basierend ist. Hat die Java-Swing-Welt da eine wichtige Entwicklung verpasst oder kann SWT etwas, das Swing nicht beherrscht?

Coward: Ich selbst habe SWT selten benutzt, außerdem wurde es als Konkurrent zu Java's AWT entwickelt, das dann in den späten Neunzigern als Grundlage für Swing diente. Generell denke ich natürlich, dass Wettbewerb in der Technologie-Welt gut ist: so hat zum Beispiel die Konkurrenz zwischen Eclipse und NetBeans beide Technologien verbessert - sie haben sich gegenseitig Ideen abgeguckt, ausgeliehen oder gestohlen. So wurden zwei gute Entwicklungsumgebungen aufgebaut, beide Java-IDEs auf ein Level gebracht und sogar besser gemacht als die Tools von Microsoft. Viel interessanter für mich ist die Frage, ob das Eclipse-Team eine Java-basierte RIA-Technologie wie JavaFX für den RIA-Raum entwickeln wird, um Java (in Bezug auf welches sowohl IBM als auch Sun Champions sind) dabei zu helfen, besser mit Adobe's Flex und Microsoft's Silverlight zu konkurrieren.