Blick hinter die Kulissen: Ein erster Eindruck zu JavaFX 1.0

On Stage

Wie bereits beschrieben, muss der Entwickler nicht mehr zwischen dem Ziel – Applet oder Desktop- bzw. Mobile-Anwendung – unterscheiden. Die Basis einer UI-basierten Anwendung bildet immer die Klasse Stage. Innerhalb einer Stage existiert eine Hierarchie von grafischen Elementen, Nodes, die sich in Form einer Scene präsentieren und somit die UI deklarativ beschreiben.

Ein Node wiederum kann eine vorgegebene JavaFX-Komponente sein – z. B. ein Image, Rectangle, Text, MediaView oder eine der gewrappten Swing-Komponenten, um nur einige zu nennen – oder aber ein CustomNode, d. h. eine selbstgeschriebene JavaFX-Klasse, die sich in der Regel aus der Aggregation anderer Nodes zusammen setzt. Die dritte Alternative für einen Node bildet die Group, eine Art Container, auf dem zusätzlich Transformationen, z. B. Rotationen oder Skalierungen, ausgeführt werden können, die sich dann auf allen Komponenten der Group auswirken.

Möchte man dennoch Besonderheiten der Zielplattform ausnutzen, so lässt sich dies via StageExtension erreichen, die in das Stage-Element eingebetet werden können. Eine erste Implementierung existiert in Form der AppletStageExtension, die – wie es der Name schon nahelegt – für Applets verwendet werden kann und dort u. a. die Möglichkeit bietet, auf das Drag-and-Drop-Ereignis eines JavaFX Applets auf dem Desktop zu reagieren.

Rien ne va plus …

Versucht man eine für das Preview SDK geschriebene Anwendung unter JavaFX 1.0 zum Laufen zu bekommen, so wird dies mit hoher Wahrscheinlichkeit nicht von Erfolg gekrönt sein. Zu stark sind die Unterschiede der beiden Versionen. Angefangen bei dem Wegfall des allgemein als eher verwirrend angesehenen Schlüsselworts attribute, hin zur Ergänzung aller Swing-basierten Komponenten um den Namenspräfix Swing, bis zur völligen Neugestaltung der vorherigen Package-Struktur scheint es mehr Änderungen als Gewohntes zu geben. Dass die Änderungen am Ende doch weniger stark sind als sie zunächst scheinen und in der Regel dazu noch absolut sinnvoll, zeigt ein Selbstversuch anhand der Migration des von mir implementierten JavaFX-Beispiels aus. Die gesamte Anwendung war in weniger als einer Stunde portiert.

JavaFX Script ist nicht Java

Noch deutlicher als schon beim Preview SDK wird es durch das aktuelle Release 1.0, dass es sich bei JavaFX Script nicht um ein Script-Derivat der Sprache Java, sondern um eine auf Visualisierung spezialisierte DSL handelt.

Neben „Kleinigkeiten“ wie dem Schlüsselwort def zum Deklarieren von Konstanten oder dem Schlüsselwort override zum Markieren einer überschriebenen Funktion oder Variable, weichen insbesondere die für die Version 1.0 noch einmal überarbeiteten JavaFX Access Modifier stark von ihren Java-Pendants ab:

  • script-private
  • package
  • protected
  • public
  • public-read
  • public-init

Wird kein expliziter Access Modifier bei der Deklaration einer Variable oder einer Funktion angegeben, ist der Zugriff automatisch script-private, d. h. auf das aktuelle JavaFX Script begrenzt. Interessant ist, dass man diesen Access Modifier selbst nicht angeben kann, da er als Schlüsselwort nicht erkannt wird.

Der Access Modifier package ist selbsterklärend und äquivalent zu dem Java-Default-Wert. Die Access Modifier protected und public sind ebenfalls aus der Java-Welt bekannt und haben in JavaFX die gleiche Sichtbarkeit. Bedingt durch die Tatsache, dass JavaFX weder getter/setter-Methoden noch Konstruktoren kennt, erweitert sich das Spektrum der Access Modifier um die beiden Varianten public-read (read-only-Zugriff von außen) und public-init (lediglich einmalige Initialisierung von außen). Ebenfalls neu und für den Java-Entwickler ungewohnt dürfte die Tatsache sein, dass sich verschiedene Access Modifier in JavaFX kombinieren lassen. So kann z. B. mit package public-read angegeben werden, dass zwar alle JavaFX Scripte eine Variable lesen, aber nur Scripte aus demselben Package diese auch schreiben dürfen.

Aller Einstieg ist leicht

Wenn ich in meinem Artikel bereits behauptet habe, dass ich eine Menge Spaß beim Ausprobieren der JavaFX-Technologie hatte, so müsste ich nun bei dem offiziellen Release eigentlich vermelden, dass derselbige kaum noch zu übertreffen ist. Zumal sich die NetBeans-Integration – jetzt in NetBeans 6.5 – noch einmal verbessert hat und aus dem eher unscheinbaren Projekt Nile eine ausgewachsene JavaFX 1.0 Production Suite geworden ist. Man darf aber an dieser Stelle nicht vergessen, dass es sich bei dem vorliegenden JavaFX-1.0-Release nicht mehr um ein BETA-DRAFT-PUBLIC-TRY-ME handelt, sondern um den real gewordenen, von Sun viel gepriesenen Herausforderer von Flash/Flex, Silverlight und Co. Ob JavaFX den selbst gestellten Anforderungen gerecht werden kann, muss die Zukunft zeigen.

Sun zumindest hat nun endlich alle Zeichen auf „volle Fahrt voraus“ gesetzt und sowohl mit JavaFX 1.0 selbst als auch mit dem zugehörigen Umfeld, d. h. Toolsupport, Tutorials, Dokumentation etc. eine gute Basis geschaffen. Jetzt heißt es – für Sun – am Ball bleiben und den eventuell in den letzten 500 Tagen verlorenen Boden wieder gut machen.

Lars Röwekamp, Gründer des IT-Beratungs- und Entwicklungsunternehmens OpenKnowledge GmbH, beschäftigt sich mit der eingehenden Analyse und Bewertung neuer Software- und Technologietrends. Ein besonderer Schwerpunkt seiner Arbeit liegt auf den Bereichen Enterprise und Mobile Computing, wobei neben Design- und Architekturfragen insbesondere die Reallife-Aspekte im Fokus seiner Betrachtung stehen. Lars Röwekamp, Autor mehrerer Fachartikel und -bücher, beschäftigt sich seit der Geburtsstunde von Java mit dieser Programmiersprache, wobei er einen Großteil seiner praktischen Erfahrungen im Rahmen großer, internationaler Projekte sammeln konnte.
Kommentare

Schreibe einen Kommentar

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