Oder wie JavaFX neue Sprachen entdeckt

Der Abschied von JavaFX Script

Andreas Schosser

Mit den Ankündigungen der JavaFX 2.0 Roadmap [1] hat sich Oracle viel vorgenommen. Inzwischen sind bereits einige Insider-Informationen über frühe Vorabversionen an die Öffentlichkeit gedrungen. Aber außer dem Hinweis, dass sich JavaFX 2.0 „deutlich schneller anfühlt“ und bereits jetzt einige der angekündigten Features enthält [2], ist das Feedback bislang doch eher zurückhaltend. Die spannende Frage, was es zum Beispiel mit den neuen API-Ankündigungen bezüglich JRuby, Clojure, Groovy, Scala, (Fantom, Myra, Jython) und nicht zu vergessen Java auf sich hat, blieb bisher weitestgehend unbeantwortet. Während sich Oracle momentan eher bedeckt hält und sich verstärkt auf eine neue Java API konzentriert, ernennt die Open Source Community um Stephen Chin die junge Sprache Visage zum Thronfolger von JavaFX Script [3]. Doch wo geht die Reise hin? Wie werden die JavaFX-Anwendungen von Morgen entwickelt werden und vor allem in welcher Sprache?

Nicht erst seit der JavaOne 2010 diskutieren Fachleute die Zukunft von JavaFX Script. Denn so nötig die Einführung einer deklarativen Sprache zur Beschreibung grafischer Oberflächen schien, so schwer fiel es JavaFX Script, sich als neue proprietäre GUI-Sprache zu behaupten. Der vorliegende Artikel skizziert, wie JavaFX 2.0 zukünftig DataBinding in Java ermöglichen wird und wie über die neue API auch Schnittstellen zu anderen VM-Sprachen wie Visage, aber auch Groovy oder Scala geschaffen werden können. Dabei versucht der Artikel, die Vor- und Nachteile der Verwendung von Java, aber auch neuer Sprachen, kritisch zu durchleuchten.

JavaFX spricht Java

Eine in den Java-Standardbibliotheken bereits lange erwartete Neuerung und ein Herzstück der modernen GUI-Entwicklung ist die Realisierung eines flexiblen DataBindings. Während zum Beispiel in Swing ein transparentes Binding bislang ausschließlich über Zusatzbibliotheken wie SwingX oder JGoodies realisiert werden konnte, stellt JavaFX 1.3 heute ein in der Java-Welt unerreichtes, flexibles und überaus mächtiges Data-Binding bereit (vgl. [4]). Die mit JavaFX 2.0 angekündigte Java API bedient sich dieser neuen Binding-Strategien, übersetzt die bisherige JavaFX Script API jedoch in natives Java. Das Ergebnis hiervon dürfte auf den ersten Blick zunächst nicht unbedingt überraschend erscheinen und vielleicht sogar an das DataBinding mit SwingX oder JGoodies erinnern (vgl. Listing 1).

Listing 1: Herkömmliches Swing-DataBinding mit JGoodies
Person person = new Person();
person.setLastName("Meyer");
ValueModel adapter = new PropertyAdapter(person, "lastName", true);
JTextField textField = BasicComponentFactory.createTextField(adapter);

Entsprechend den bisherigen Veröffentlichungen zu JavaFX 2.0 orientieren sich einige Aspekte der neuen API-Implementierung an ihrem inoffiziellen Vorgänger, Swing. Die konkrete Umsetzung der neuen DataBinding-Strategien weicht zwar von den bekannten Ansätzen in JGoodies und SwingX ab, basiert jedoch auf ähnliche Art und Weise auf der Verwendung von JavaBeans und PropertyChangeListenern (vgl. [5]).

JavaFX 2.0 gleich Swing 2.0?

Infolge der augenscheinlichen Verwandtschaft der neuen JavaFX API mit Swing stellt sich vielleicht die Frage, ob es sich bei JavaFX 2.0 schlicht um ein verbessertes Swing-Framework handelt. Bei eingehender Betrachtung der Java-Schnittstelle fällt jedoch schnell auf, dass die neue API wesentlich mehr bietet, als bisher zum Beispiel mit Swing (und JGoodies) möglich war. Durch die geschickte Verwendung von Lazy-Aufrufen (und in Zukunft auch mit Hilfe von Closures), wird zunächst die Performance während der Initialisierung gegenüber klassischem Java-Binding drastisch verbessert.

Parallel dazu werden so genannte „Pseudo-Properties“ eingeführt, die zum Beispiel ein einfaches Binding für Mouse-Over (Hover) oder benutzergesteuerte Ereignisse ermöglichen (vgl. Listing 2).

Listing 2: Fiktives Beispiel für ein JavaFX Pseudo-Property (
adaptiert in Anlehnung an [5])
final Label label = new Label();
label.setText( "Do not touch." );
label.addChangeListener( Label.HOVER, new ChangeListener() {
    public void handle( Bean bean, PropertyReference pr ) {
        label.setText ("Go away!" );
    }
} );

Neben derartigen Pseudo-Properties und erweitertem DataBinding werden mit der neuen API auch bereits aus JavaFX Script bekannte Bitmap-Effekte wie Blur, Drop-Shadow, Glow usw. möglich sein. Eine offene Frage bleibt weiterhin, wie mit der Java-Schnittstelle Animationen über Sequenzen und Timelines – und damit ohne umständliche Thread-Synchronisierung – abgebildet werden können (vgl. [5]).

Java API vs. deklarative DSL

Sofern mit der neuen Java API alle wichtigen Neuerungen von JavaFX abgebildet werden, so scheint es zunächst unklar, weshalb überhaupt noch eine deklarative Sprache wie JavaFX Script erforderlich sein sollte. Wie in Tabelle 1 gezeigt, unterscheiden sich Java und deklarative GUI-APIs vor allem in der Abbildung der Struktur von grafischen Elementen im Quellcode.

Tabelle 1: Vergleich einer Anwendung auf Java API und deklarativer API

Java API deklarative API: Scala-DSL

public Stage createStage() {
    Stage stage = new Stage();
    stage.setTitle("Hello JavaFX 2.0");
    Scene scene = new Scene(stage);
    scene.setWidth(800);
    scene.setHeight(600);
    Label label = new Label(scene);
    label.setText("Welcome");
    scene.add(label);
    .
}

stage = new Stage {
    title  = "Hello JavaFX 2.0"
    scene = new Scene {
        width = 800
        height = 600
        content = new Content {
            label = new Label {
                text = "Welcome"
            }
            .
        }
    }
}

Beim Einsatz einer Java basierenden API werden Struktur und Aufbau grafischer Elemente programmatisch festgelegt. So wird zum Beispiel die Verknüpfung von Eltern- und Kind-Elementen häufig durch Übergabe von Referenzen bei der Objekt-Initialisierung im Konstruktor oder mit Hilfe von Add-Methodenaufrufen festgelegt. Der exakte Aufbau einer komplexen grafischen Komponente ist daher ausschließlich durch eine Analyse interner Übergabe-Parameter möglich.

Anders als bei Java basierten APIs spiegeln deklarative GUI-DSLs die Verschachtelungsstruktur grafischer Elemente in den Sourcen wider. Im aufgeführten Beispiel erscheint daher ein Label-Objekt innerhalb eines Szene- bzw. Content-Blocks. Bei einheitlicher Formatierung ist der Kontext zwischen Kind- und Eltern-Elementen daher immer direkt anhand der Einrückungen ersichtlich. Diese transparente Spiegelung der grafischen Objektstruktur kann in einigen Fällen die Anordnung und Platzierung komplexer grafischer Strukturen wesentlich erleichtern.

Geschrieben von
Andreas Schosser
Kommentare

Schreibe einen Kommentar

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