Java-Desktop-GUIs wurden in der Vergangenheit vom Java-Erfinder Sun Microsystems oftmals stiefmütterlich behandelt. Anfangs mussten Java-Entwickler mit den Unzulänglichkeiten der Java-Frameworks "Abstract Window Toolkit" (AWT) und "Swing" kämpfen. Das ging so weit, dass sich IBM im Jahr 2001 entschloss, zwei neue Java-Frameworks für die Entwicklung der Eclipse-IDE zu entwickeln – die Java-Community war ab diesem Moment bei der Entwicklung von Java-Desktop-Anwendungen gespalten.
Foto: iamwayclick - shutterstock.com
Die Sun-Getreuen setzten weiterhin auf AWT/Swing, die IBM-Gefolgschaft auf SWT/JFace. Für die AWT/Swing-Anhänger gab es im Jahr 2007 einen unerwarteten Dämpfer. Damals kündigte Sun Microsystems an, das in die Jahre gekommene AWT/Swing-Gespann durch das moderne JavaFX ersetzen zu wollen (Java-FAQs).
Neuausrichtung bei Java 11
JavaFX beruht auf einer vollkommen neu entwickelten Architektur und schöpft beispielsweise die Fähigkeiten moderner Grafikprozessoren weit besser aus als die Vorläufer. Es sollte gegen Silverlight und Flash konkurrieren können. Wer in den vergangenen Jahren seine Java-Swing-Anwendungen auf das JavaFX-Framework migriert hatte, muss im März diesen Jahres gedacht haben, damit einen Fehler begangen zu haben. Zu diesem Zeitpunkt kündigte das Oracle-Produktmanagement in einem Blog an, bestimmte Client-Technologien wie Java-Webstart, den Java-Packager und das UI-Framework JavaFX aus dem JDK auszugliedern. Jetzt, nachdem Java 11 erschienen ist, bedeutet das in Zusammenhang mit dem neuen Java-Lizenzmodell für manche Firmen erhebliche Umstellungen, denn für Webstart gibt es keinen kompatiblen Ersatz, und die Zukunft von JavaFX erscheint ebenfalls unsicher.
Lesen Sie mehr rund um das Thema Java:
Natürlich hat jeder Hersteller eines Frameworks das gute Recht, die Entwicklung aus verschiedenen Gründen einzustellen. Das lässt sich zum Beispiel aufgrund des technischen Fortschritts oftmals überhaupt nicht vermeiden. Bei Java Webstart und JavaFX kann man das jedoch nicht behaupten. Trotz des unzweifelhaften Siegeszugs von Webanwendungen, haben beide Technologien weiterhin ihre Berechtigung. Insbesondere ist JavaFX praktisch nicht ohne weiteres zu ersetzen, denn eine GUI-Technologie lässt sich aufgrund des hohen Entwicklungsaufwands bei professionellen Java-Desktop-Anwendungen schon aus wirtschaftlichen Erwägungen nicht alle paar Jahre migrieren. Viele Softwarehäuser und Entwicklungsabteilungen fragen sich daher seit der Oracle-Ankündigung, wie die Zukunft ihrer Produkte aussieht.
Bye, bye, Java Webstart
Für die Weiterentwicklung von Java Webstart sieht es düster aus. Oracle empfiehlt in seiner Java SE Support Roadmap die in Java 9 eingeführte neue Paketierungsoption JLink zu nutzen. Hierbei scheint die zukünftige Strategie zu sein, eine client-spezifische Java-Laufzeitumgebung (JRE) in eine Desktop-Anwendung einzubetten, wie man dem Whitepaper zur Client-Roadmap von Oracle entnehmen kann. Das lässt sich als Empfehlung von Oracle interpretieren, Java-Desktop-Anwendungen immer zusammen mit einer für sie passenden Java-Laufzeitumgebung auszuliefern. Der Gedanke ist nicht neu. Die Umsetzung war nur aus lizenzrechtlichen Gründen vor einigen Jahren noch nicht erlaubt, weswegen Webstart überhaupt erst etabliert wurde.
Die Vorteile des Vorgehens, eine JRE in die Desktop-Anwendung einzubetten, liegen auf der Hand: Wenn man vermeidet, dass eine Java-Desktop-Anwendung eine bereits installierte Java-Laufzeitumgebung nutzt, vermeidet man Probleme, die auftreten, wenn eine neuere Versionen der Laufzeitumgebung auf dem Client-Computer installiert wird, die nicht mehr zu Anwendung kompatibel ist. Die Anwendung wäre mit einer eingebettenen Java-Laufzeitung stattdessen vollkommen autark von der Installation auf dem Client-Computer. Der einzige Nachteil des Verfahrens ist, dass die Verteilpakete größer werden, weil sich mehrere Java-Desktop-Anwendungen nicht mehr lediglich eine Java-Laufzeitumgebung teilen. Angesichts der heute sehr preiswerten Festplattenkapazität ist das aber leicht zu verschmerzen.
Lesen Sie mehr zum Thema Oracle:
Ist das Programm dann erst einmal auf dem Rechner des Endanwenders mit einer eigenen Java-Laufzeitumgebung vorhanden, kann es sich mit einem geeigneten Update-Verfahren selbsttätig überprüfen und gegebenenfalls aktualisieren. Dieses Verfahren wird beispielsweise von Programmen auf Basis von Eclipse RCP seit Jahren erfolgreich praktiziert. Wer kein Eclipse RCP nutzt, dem stehen andere Alternativen wie zum Beispiel FXLauncher, GetDown, Java-Auto-Update oder UpdateFX, zur Verfügung. Sie erlauben ebenfalls eine automatisierte Aktualisierung von Java-Desktop-Anwendungen. Alle genannten Verfahren sind geeignet, Java Webstart zu ersetzen. Eine Migration der Anwendungen ist hierbei natürlich notwendig.
Aus JavaFX wird OpenJFX
Oracle begründet seinen Schritt, JavaFX aus dem JDK auszugliedern, dass das helfe, das JDK zu entschlacken und den Entwicklern in einem ausgegliederten JavaFX mehr Freiheiten zu bieten. Eine Freiheit könnte zum Beispiel sein, den Release-Zyklus anders zu wählen als die Java-Basis, die jedes halbe Jahr erneuert wird. Mittlerweile scheint die Weiterentwicklung von JavaFX gesichert. Hierfür zeichnet der Softwarehersteller Gluon verantwortlich. Gluon ist ein von fünf Java-Experten im Jahr 2015 gegründetes kleines Softwarehaus, das man nicht mit dem gleichnamigen Quark-Tochterunternehmen verwechseln sollte. Gluon ist im Gegensatz zur Quark-Tochter auf die Entwicklung von Mobilanwendungen spezialisiert. Das Unternehmen ist bereits durch die Übernahme der Weiterentwicklung des JavaFX-Tools "Scene Builder" von Oracle bekannt geworden.
Oracle ändert Lizenzmodell: Kostenexplosion bei Java?
Mittlerweile hat Gluon zusammen mit Oracle das erste neue JavaFX-Release als Version 11 unter dem neuen Namen OpenJFX veröffentlicht und eine OpenJFX-Website eingerichtet. OpenJFX wird in Zukunft wie auch das JDK unter der GPL mit Classpath Exception vertrieben. Diese Lizenz gestattet es, kommerzielle Software zu entwickeln und unter einer eigenen Lizenz weiter zu vertreiben. Unternehmen, die auf JavaFX gesetzt haben, können also vorerst aufatmen. Einerseits ist mit Gluon ein namhaftes Unternehmen für die Weiterentwicklung von JavaFX gefunden. Andererseits ist eine weitere Absicherung vorhanden, da sich Oracle JDK 8 kostenpflichtig bis mindestens zum Jahr 2022 lizenzieren lässt. Somit haben Unternehmen mit den zwei genannten Optionen relativ lange Zeit, die GUI-Entwicklung ihrer Desktop-Anwendungen neu auszurichten.
Fazit
Dass Oracle Ordnung in das Erbe von Sun Microsystems bringen möchte und dazu Altlasten aus dem JDK entfernt, ist nur allzu verständlich. Die Art und Weise, wie Oracle jedoch seine strategischen Vorhaben in den verschiedensten Veröffentlichungen ankündigt, kann man aus PR-Sicht nur als dilletantisch bezeichnen. Was zur Entwicklung von Java-Desktop-Anwendungen fehlt, ist eine klare und vor allem fundierte Aussage, wie die Entwicklung von Java-Anwendungen und Apps in den nächsten Jahren verlaufen soll. Ist weiterhin keine klare Strategie zu erkennen, setzt Oracle das Vertrauen von Java-Softwarehäusern und Unternehmensabteilungen leichtfertig aufs Spiel.