Whitepaper EVOLUTION STATT STAGNATION - VON SWING NACH JAVA FX

Transkript

1 Whitepaper EVOLUTION STATT STAGNATION - VON SWING NACH JAVA FX

2 Evolution statt Stagnation: WELCHE TECHNOLOGIE PASST ZU MEINEM SOFTWAREPROJEKT? SWING TO JAVA FX

3 Evolution statt Stagnation: FRAGEN ÜBER FRAGEN... Welches Oberflächenframework soll für das neue Projekt verwendet werden? Welches ist am besten geeignet, um die Anforderungen einer modernen Softwarelösung zu bewältigen? Können wir dieses Framework auch für die Migration unserer älteren Projekte verwenden? Diese und noch viele weitere Fragen stellen sich Architekten und Projektmanager, wenn Sie vor der Entscheidung stehen, welche Technologien für ein Softwareprojekt eingesetzt werden sollen. In dem Fall von Desktopanwendungen im Java-Bereich waren die Antwortmöglichkeiten relativ übersichtlich. AWT war bereits im letzten Jahrzehnt veraltet und wurde nicht mehr eingesetzt. Blieben als Alternativen noch Swing und SWT übrig. Trotz anfänglicher Performance-Schwierigkeiten wurde Swing, dank seiner modularen Struktur, seiner Plattformunabhängigkeit, anfänglich Beginn noch notwendiger Verbesserungen und Weiterentwicklungen, ein Erfolg. Doch in Zeiten von Android, ios und Windows 8 sehen Swing - Anwendungen zum einen nicht mehr zeitgemäß aus und werden zum anderen auch nicht mehr aktiv von Oracle unterstützt. Die Neuerungen für Swing in Java 7 hielten sich in Grenzen (Nimbus Look & Feel, JLayer-Komponente) und beibehalten in Java 8 beinhaltet ebenfalls keine großen Weiterentwicklungen. Auch die Implementierung von (aufwendigen) Effekten und Animationen, die für andere Oberflächen-Frameworks Standard sind (Schatten, Smooth Scrolling, Reflektionen u.v.m.), können sich mit Swing sehr aufwendig gestalten oder nicht umgesetzt werden. Für eine Neuentwicklung scheidet somit auch Swing als Oberflächentechnologie aus, was nicht bedeutet dass es noch in vielen älteren Projekten im Einsatz ist und sich in der Praxis bewährt hat. Werden nun neue Anforderungen an die Software gestellt oder die Ausrichtung festgelegt die Anwendung fit für die Zukunft zu machen, ist JavaFX die erste Wahl für Desktopanwendungen und somit auch für eine Migration älterer Swing- Applikationen.

4 Swing to JavaFX: DIE VORRAUSSETZUNGEN EINER ERFOLGREICHEN MIGRATION SWING TO JAVA FX

5 Swing to JavaFX: DIE DREI ERFOLGSBAUSTEINE... Bevor jedoch die Migration einer Swing-Applikation nach JavaFX vollzogen werden kann, müssen bestimmte Vorrausetzungen erfüllt sein, um bereits ein frühzeitiges Scheitern zu vermeiden. Diese können in drei verschiedene Kategorien eingeteilt werden: Technologie Architektur Fachwissen Technologische Vorbedingung einer Migration ist die Verwendung von Java 7 oder Java 8. Java 7 war die erste Java-Version, bei der JavaFX überhaupt mitinstalliert wurde und bildet somit die Grundlage, um JavaFX-Code programmieren zu können. Weiterhin bietet Java 7 die Möglichkeit, mit dem JFXPanel JavaFX- Komponenten in Swing einzubetten. Folgt hingegen das Projektziel dem Ansatz, alte Swing-Komponenten für eine Übergangszeit weiter zu verwenden, muss Java 8 zum Einsatz kommen. Erst mit der aktuellen Java-Version wurde die JavaFX- Komponente SwingNode eingeführt, die es erlaubt, Swing-Module in JavaFX zu verwenden. Die vorherrschende Architektur des Projektes spielt ebenfalls eine wesentliche Rolle in der Migrationsstrategie. Jede Applikation wird von den Architekten mit eine klaren Trennung von Oberfläche und Programmlogik konzipiert. Jedoch kommt es besonders bei langfristigen Projekten zu dem Problem, dass immer mehr Geschäftslogik in die Oberfläche ausgelagert wird, sei es durch Bug-fixes, neue Mitarbeiter oder verlorenes und unvollständiges Fachwissen. Ein vorgelagertes Refactoring der Applikation dient in diesem Fall der Vorbereitung für die Umstellung auf JavaFX. Liegt trotz aller externen Faktoren weiterhin oder wieder eine klare architektonische Trennung vor, wird die Migration deutlich leichter durchzuführen sein. Das benötigte Fachwissen über JavaFX beschreibt den letzten Punkt der Vorrausetzungen. Hiermit ist weniger das Wissen über die konkrete Implementierung gemeint, sondern über die Möglichkeiten und Neuerungen die JavaFX bietet. Als Stichworte können hier FXML und Bindings genannt werden. Zwei sinnvolle Konzepte, die bei der Migration auf JavaFX eingesetzt, aber auch ignoriert werden können.

6 Die Besonderheiten: WAS HAT JAVA FX WAS SWING NICHT HAT? SWING TO JAVA FX

7 Die Besonderheiten: ZEITGEMÄSSES LOOK & FEEL Der größte sofort sichtbare Unterschied von JavaFX gegenüber Swing ist das zeitgemäße Look & Feel der Anwendungen, den die heutigen User von Tablet und Webanwendungen gewöhnt sind. Dabei ist die Erstellung von komplexen Animationen, Effekten und Schatten genauso einfach, wie die Erzeugung von Zufallszahlen, da JavaFX für alle Anforderungen vordefinierte Klassen bereitstellt. Weitere Besonderheiten sind die Einführung von Bindings und die in anderen Programmiersprachen bereits verwendete Auslagerung der Beschreibung des Aussehens von Oberflächen in XML-Dateien (FXML). Das Konzept der JavaBeans ist jedem Architekten und Entwickler geläufig. Änderungen des Zustands einer Bean werden dabei über Setter-Methoden ausgeführt. JavaFX-Bindings basieren auf diesem Konzept, verbessern und erweitern dieses, indem direkte Beziehungen zwischen den Variablen hergestellt werden. Listing 1 StringProperty vorname = new SimpleStringProperty(); StringProperty nachname = new SmpleStringProperty(); StringProperty gesamtername = new SimpleStringProperty(); gesamtername.bind(bindings.concat(vorname,, nachname)); Ende Änderungen an den Werten werden automatisch an alle anderen an das Objekt gebundene Objekte verschickt, so dass eine manuelle Änderung unnötig ist. Daraus resultiert eine deutliche Codereduktion in den GUI-Klassen, da die in Swing benötigten Eventlisteners und Action-Methoden entfallen. Weiterhin ist es sehr einfach, zusätzliche GUI-Komponenten an das Datenmodell anzubinden. Ein simples bind an die Variable genügt und alle Änderungen werden an die Oberfläche weitergereicht. Durch FXML bietet sich dem Entwickler die Möglichkeit, das Design der Oberflächen von der Entwicklung zu trennen. Die Beschreibung von Aussehen und die exakte Anordnung der Komponenten sind über CSS möglich. Aufwändige Fragen zu der Gestaltung der Oberflächen können somit dem Designteam überlassen und das Entwicklerteam gleichzeitig entlastet werden. Weitere Vorteile sind die höhere, durch weitere Codereduktion erzielte Lesbarkeit des Java-Codes und die einfache Erstellung von FXML durch zusätzliche Tools wie dem JavaFX Scene Builder.

8 Der Weg zum Ziel: DIE VIER MIGRATIONSSTRATEGIEN SWING TO JAVA FX

9 Der Weg zum Ziel: DIE VIER STRATEGIEN Für die Migration einer Swing-Anwendung nach JavaFX existieren grundlegend vier verschiedene Strategien. NEUENTWICKLUNG DIVIDE & CONQUER Entwicklung einer klaren Architektur mit und nach JavaFX Vorteile Inversion of Control Nachteile Benötigte Zeit und Budget bis zur lauffähigen Anwendung Allzeit lauffähige (Teil-) JavaFX-Anwendung durch schrittweise Umstellung Vorteile Inversion of Control Swing-Altlasten bleiben erhalten Nachteile Keine Swing-Altlasten Lauffähige JavaFX-Version existiert erst nach der kompletten Migration Absehbare Zeit und Budget für die Umstellung einzelner Komponenten Mögliche Architekturanpassung, um die JavaFX-Komponenten einsetzen zu können JavaFX ohne FXML JavaFX mit FXML JFXPanel (JavaFX in Swing) SwingNode (Swing in JavaFX) Eine erste Unterscheidung erfolgt in einer vollständigen Migration der Oberfläche oder in einer schrittweisen Umstellung, hier Divide & Conquer genannt. Beide Varianten haben dabei ihre Vor- und Nachteile. Entscheidet sich das Projektteam für eine Ausrichtung, muss noch die genaue Umsetzungsstrategie gewählt werden.

10 Der Weg zum Ziel: DIVIDE & CONQUER Als allgemeine Vorbedingung für die Anwendung der Divide & Conquer Strategie gilt eine klare Trennung von Oberfläche/GUI und Logik/Datenmodell. So kann verhindert werden, dass bei der Umstellung auf JavaFX zusätzliche Zeit in die erneute Implementierung der Programmlogik investiert werden muss, wie in dem Abschnitt Vorrausetzungen einer erfolgreichen Migration angesprochen. JFXPanel Mit dem JFXPanel wurde in Swing schon früh die Möglichkeit geschaffen, JavaFX- Komponenten einzubetten. Das JFXPanel ist dafür Teil der Swing-Hierarchie und direkt unter JComponent angeordnet. Divide & Conquer besitzt selbst nochmals zwei Unterteilungen: JFXPanel SwingNode Vererbungshierarchie des JFXPanel Somit kann das JFXPanel in jedem JFrame hinzugefügt und als Teil der Swing- Oberfläche angezeigt werden. Um JavaFX-Elemente zu verwenden, besitzt das JFXPanel folgende Methoden: setscene getscene

11 Der Weg zum Ziel: DIVIDE & CONQUER Mit setscene kann dem JFXPanel eine JavaFX-Komponente hinzugefügt werden. Zu beachten ist, dass der Aufruf auf dem JavaFX-Event-Thread ausgeführt wird, da sonst eine Exception auftritt (Exception in thread AWT-Event- Queue-0 java.lang.illegalstateexception: Not on FX application thread; currentthread = AWT-EventQueue-0). In Listing 2 ist die korrekte Anwendung dargestellt. Der Aufruf von Platform.runLater kann auch über einen Lambda-Ausdruck geschehen. Listing 2 public class FXSceneForSwing extends JFXPanel { Platform.runLater(new Runnable() public void run() { setscene(new Scene(/* Setzen der Scene */)); } }); } Ende In Swing besteht die Möglichkeit, JavaFX-Komponenten, beispielsweise Tabellen (TableView), darzustellen. Die JavaFX-Tabelle behält dabei alle Eigenschaften, wie das automatische Sortieren von Zeilen oder das Umgruppieren der Spalten, bei. Auch das Look & Feel von JavaFX wird übernommen, so dass eine optische Abgrenzung zu den Swing-Komponenten existiert. Die Verwendung von JavaFX-Properties und das Propertybinding können nicht ohne zusätzliche Anpassungen geschehen. Bei der Erweiterung des Datenmodells müssen alle einfachen Datentypen durch Properties (z. Bsp. SimpleString- Property) und den entsprechenden getter-methoden ergänzt werden. Damit bestehende Swing-GUI-Komponenten weiterhin einsetzbar bleiben, müssen die existierenden getter-methoden erhalten bleiben. Dieses Modell kann als Hybridmodell verstanden werden. Man kann auf das hilfreiche Feature der Bindings auch komplett verzichten und alle Änderungen am Datenmodell weiterhin durch Eventlistener an die Oberflächen propagieren. Die Kommunikation zwischen Swing und JavaFX-Komponenten ist ebenfalls problemlos möglich. Es ist aber darauf zu achten, dass Änderungen auf dem korrekten Event-Thread der GUI-Komponente durchgeführt werden. Mit dem JFXPanel besitzt der Entwickler die Chance, alle JavaFX-Komponenten problemlos in seiner Swing-Anwendung einzusetzen.

12 Der Weg zum Ziel: DIVIDE & CONQUER SwingNode Die SwingNode bietet ab Java 8 die Möglichkeit, Swing-Komponenten in JavaFX zu verwenden. Sie ist ein Teil der JavaFX-Hierarchie und direkt unter Node angeordnet. Listing 3 public class SwingPanelForFX extends SwingNode { SwingUtilities.invokeLater(new Runnable() public void run() { setcontent(/* Setzen des JPanels */); } }); } Ende Vererbungshierarchie der SwingNode Für die Integration von Swing-Komponenten in JavaFX existieren folgende Methoden: setcontent getcontent Durch setcontent kann der SwingNode eine JComponent hinzugefügt werden. Das Setzen der Komponente muss auf dem Swing-EDT (Event-Dispatchter-Thread) erfolgen, da ansonsten standardmäßig der JavaFX Thread verwendet wird, was eine Exception zur Folge haben könnte. Die Kommunikation zwischen JavaFX und Swing-Komponenten funktioniert auch in dieser Richtung ohne Schwierigkeiten. Besondere Aufmerksamkeit sollte man der Anbindung des Datenmodells widmen. Da die Verwendung von JavaFX-Properties in Swing nicht möglich ist, müssen nachträglich andere Pattern, wie MVC, benutzt werden, um Änderungen an die Oberfläche zu propagieren. Mit einem erhöhten Arbeitsaufwand im Front- und Backend-Bereich ist dabei zu rechnen. Durch die Entwicklung der SwingNode schließt Oracle den Kreis für die Migration von Swing nach JavaFX und gibt dem Entwickler alle Werkzeuge an die Hand, um bestehende Swing-Applikationen zu modernisieren.

13 Das Fazit: DIVIDE & CONQUER Beide Varianten, Swing in JavaFX und JavaFX in Swing, sind technisch möglich und bieten den Entwicklern die Möglichkeit, bestehende Swing-Anwendungen nach JavaFX zu migrieren. Besonders geeignet ist diese Form der Migration von Swing nach JavaFX für Anwendungen, die in kleinen Abschnitten portiert werden sollen. Daraus ergeben sich Vorteile, wie die schnelle Umsetzung neuer Features, die zeitnahe Erprobung der Komponenten durch Endanwender sowie deren Feedback, welche in die weitere Entwicklung einfließen können. Jede Komponente kann dabei Schritt für Schritt ausgetauscht und das JavaFX-Wissen dadurch ausgebaut werden. Die Weiterverwendung bestehender, komplexer Swing-Komponenten und der dadurch vermiedene Nachbau in JavaFX können den Entwicklungsaufwand senken. Nachteil dieser Strategie sind die Swing-Altlasten, welche während der Migration in der Anwendung verbleiben, wie zum Beispiel EventListener im Datenmodell. Falls die Verwendung von JavaFX-Properties gefordert ist, ist eine Erweiterung des Datenmodells unumgänglich

14 Der Weg zum Ziel: NEUENTWICKLUNG Wie bei der Migration kann man die Neuentwicklung in zwei Teilbereiche unterscheiden: JavaFX ohne FXML JavaFX mit FXML Da eine Neuentwicklung in JavaFX ohne FXML dem üblichen Vorgehen entspricht, wird in diesem Abschnitt JavaFX mit FXML vorgestellt. FXML Mit JavaFX 2.0 wurde erstmalig die Möglichkeit geschaffen, die grafische Oberfläche über eine XML-Beschreibungssprache (FXML) zu entwerfen. Dabei können nicht nur die grafischen Komponenten definiert, sondern auch das dazugehörige Layout und die Java-Controllerklasse, die unter anderem Button-Events entgegennimmt, angegeben werden. Listing 4 <GridPane fx:controller= de.saxsys.swing2javafx.javafx.fxml. TestFXMLController xmlns:fx= alignment= center hgap= 10 vgap= 10 > <padding> <Insets top= 25 right= 25 bottom= 10 left= 25 /> </padding> <Text text= Swing2JavaFX GridPane.columnIndex= 0 GridPane.row- Index= 0 /> <TextField fx:id= pathfield GridPane.columnIndex= 0 GridPane. rowindex= 1 /> <ImageView fx:id= imageview GridPane.columnIndex= 0 GridPane. rowindex= 2 /> </GridPane> Ende

15 Der Weg zum Ziel: NEUENTWICKLUNG Listing 4 zeigt die Definition einer Oberfläche unter Verwendung einer selbst implementierten Controller-Klasse (TestFXMLController). Die JavaFX-Komponenten beinhalten zusätzlich das Attribut fx:id, über das der Controller Änderungen des Datenmodells direkt an die referenzierten Komponenten weiterleiten kann. Voraussetzung bei privaten Objekten in der Controller-Klasse ist die FXML (Listing 5). Listing 5 public class TestFXMLController private ImageView private TextField pathfield; } Ende Das Laden der FXML-Datei geschieht über den in Java enthaltenen FXMLLoader. Auch der in der FXML definierte Controller kann über diese Klasse geladen und als Java-Objekt bereitgestellt werden. FXML wurde entwickelt, um JavaFX-Oberflächen deklarativ zu beschreiben. Durch den Verbund mit dem JFXPanel ist es möglich FXML auch in Swing-Applikationen zu verwenden. Fazit Eine vollständige Migration einer Swing-Applikation nach JavaFX besitzt gegenüber einer Schritt für Schritt Anpassung den klaren Vorteil, dass die Architektur auf JavaFX ausgerichtet wird und die Übernahme von Swing-Altlasten vermieden werden kann. Ob FXML im Projekt Verwendung findet, entscheidet jedes Entwicklerteam eigenständig. Oracle bietet damit die Möglichkeit, Oberflächen deklarativ zu beschreiben und auszutauschen, indem eine andere FXML geladen wird. Einbettung von FXML in Swing

16 Systems AG: Bei der Saxonia Systems AG wird mit JavaFX bereits seit über 2 Jahren intensiv gearbeitet. Nicht nur das wir bereits Anwendungen in JavaFX programmieren und ausliefern, unsere Mitarbeiter waren und sind bei zahlreichen Veranstaltungen als Speaker unterwegs, um unser Wissen zu teilen und zu erweitern. Zusätzlich bietet die Saxonia Systems eigene Workshops an, die die Grundlagen und erweitertes Wissen rund um JavaFX vermitteln. Nähere Informationen finden Sie unter SWING TO JAVA FX