Interview mit Kai Tödter

Java Swing, SWT und JavaFX: Perspektiven der drei UI Toolkits für Java

Das Set der verfügbaren UI Toolkits für Java-Anwendungen hat mit JavaFX eine wertvolle Bereicherung erfahren. Dass JavaFX langfristig Swing ersetzen könnte, meinen viele. Doch wie sieht es mit dem Eclipse-Standard SWT aus? Laufen die Bestrebungen in der Eclipse-Community, JavaFX nahtlos in RCP-Anwendungen zu integrieren, auf eine weitere Wachablösung hinaus?

 

Wir sprachen mit Eclipse-Spezialist Kai Tödter über das Verhältnis zwischen den drei großen UI Toolkits Swing, SWT und JavaFX.

JavaFX & Eclipse

JavaFX & Eclipse ist Titelthema des aktuellen Eclipse Magazins 2.13 (ab 25. Januar am Kiosk):

  • Die Geschichte von JavaFX von den Anfängen bis heute, Claudia Fröhling
  • e(fx)clipse: JavaFX-Tooling für Eclipse, Marc Teufel
  • JavaFX 2.x und die Eclipse 4.x Application Platform: eine perfekte Ehe?, Kai Tödter
  • Ungeahnte Dimensionen für heutige Entwickler,
    Interview mit Tom Schindl über e(fx)clipse
  • JavaFX, Xtended – Active Annotations in Xtend, Sven Efftinge

Alle Infos unter www.eclipsemagazin.de.

JAXenter: Reden wir über UI Toolkits in Java. Oracle investiert ja heftig in die Entwicklung von JavaFX, das von vielen bereits als Nachfolger von Swing gehandelt wird. Hat JavaFX das Zeug dazu? An welchen Stellen muss JavaFX noch nachlegen, um tatsächlich die Nachfolge von Swing anzutreten?

Kai Tödter: Ich denke, JavaFX 2.x hat auf jeden Fall das Zeug dazu, das zukünftige Standard-UI-Toolkit für Java zu sein. Die Grundlagen sind jetzt schon sehr gut vorhanden. Es fehlen noch ein paar Widgets, wie z.B. TreeTable, aber diese sind schon in der Planung und ich rechne damit, dass das Widget-Set im Laufe der Zeit ausgebaut wird.

JAXenter: Kommen wir zum Eclipse eigenen Standard Widget Toolkit (SWT). Die Idee von SWT war es ja, die UI-Elemente des unterliegenden Betriebssystem zu nutzen. Probleme bekommt man aber dann, wenn es darum geht, ein vorgegebenes Design pixelgenau umzusetzen. Du hast das Problem eine Zeit lang über die relativ neue Möglichkeit des CSS Styling von SWT-Anwendungen zu lösen versucht. An welche Grenzen bist du gestoßen?

Kai Tödter: Die Grund-Idee von SWT ist nach wie vor, ein plattform-übergreifendes API bereitzustellen, aber wenn möglich native Betriebssystem-Widgets zu verwenden. Das API ist daher auf allen Plattformen exakt gleich. Wenn es also nicht möglich ist, auf einer unterstützten Plattform ein bestimmtes Element zu stylen, z.B. den Hintergrund des Haupt-Menüs zu setzen, wird die Möglichkeit nicht als API angeboten. Die Grenzen, an die ich gestoßen bin, liegen hauptsächlich daran, dass man z.B. unter Windows die meisten „nativen“ Widgets (Button, Scrollbar, Hauptmenü, etc.) nicht mit CSS stylen kann. Es ist zwar möglich, ein UI etwas „aufzuhübschen“, wenn man sich an die Vorgaben des zugrundeliegenden Betriebssystems hält; es ist aber nicht möglich, ein annähernd pixel-perfektes Abbild eines gegebenen Designs zu implementieren, das eben diesem Schema nicht entspricht. Im meinem Artikel „Just Married“ im aktuellen Eclipse Magazin habe ich dies ausführlich angesprochen.

JAXenter: In deinem Eclipse-Magazin Artikel beschreibst du ja, wie man eine generische Rendering Engine an die Eclipse 4.x Application Platform anbindet. Insbesondere wird es so möglich, SWT durch JavaFX zu ersetzen. Ist das Problem, „Eclipse-Anwendungen sehen eben immer nach Eclipse aus“, damit gelöst?

Kai Tödter: Ja, mit den aktuellen CSS-Styling-Möglichkeiten von JavaFX 2 kann man gegebene Designs sehr gut umsetzten und UIs entwickeln, die überhaupt nicht nach Eclipse aussehen müssen.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.