JavaFX - first (negative) impressions

As the dust on the initial release JavaFX (or JFX as its creator likes it to be called) is settling down, I tried doing some "real" work in it and the results so far are quite discouraging.

I'll omit the fact that the JFX plugin for NB 6.0M9 is more trouble than its worth (see previous blog entry). I wanted to try a very simple app that gets a JFX frontend with a JPA-powered backend.

First surprise: JFX does not support annotations

This is a really bizarre decision. Without annotations a whole class of really powerful Java functionality is unavailable to JFX, starting from JPA @Entity creation to @EJB dependency injection, etc.

So, I cannot take a JFX data class, e.g.:

class Person {
    attribute id : Number;
    attribute firstName: String;
    attribute lastName: String;
}

and turn it into a JPA entity:

@Entity
class Person {
    @Id
    attribute id : Number;
    attribute firstName: String;
    attribute lastName: String;
}

This simply does not compile.

OK, then...I guess I have to define JPA entities as regular Java classes and bind them via JFX in the UI.

Second surprise: JFX does not seem to understand Java type-safe collections / generics

I created a simple Java class called Person with a static method to return two instances of it in a List collection.

Then tried to display this in the UI via this simple JFX class:

Frame {
            height: 120
            width: 500
            title: "SimpleTableDemo"
            content: Table {
                columns:
                [TableColumn {
                    text: "First Name"
                },
                TableColumn {
                    text: "Last Name"
                }]

                cells: bind foreach (p in Person.getPersons())

                    [TableCell {
                        text:bind p.firstName
                    },
                    TableCell {
                        text:bind p.lastName
                    }]
            }
            visible: true
        }

where Person.getPersons() has a simple signature of:

public static List<Person> getPersons()

Well, this does not work, we get a runtime exception:

Main.fx:25: No such attribute firstName in class java.util.List: should be
empty

Only if I change the signature to explicitly return a Person array, i.e.

public static Person[] getPersons()

did everything work.

Needless to say, I am somewhat underwhelmed. It's nice to have Flash-style effects and everything, but if I can't easily retrieve data from the DB, pass it to the UI, bind it/display it, etc. then the tool is not very useful for your regular, everyday corporate applications.

Follow up to my previous blog: it seems like there really are no constructors in JFX, none. Only "new" triggers (like DB insert triggers). So if you have an instance variable that positively, absolutely needs to be initialized upon object creation, it seems there is no way to accomplish this (at least none that I see from the JFX manual).

And since my DBA colleagues are not that keen on triggers (things get complicated when you have multiple of them on the same object, especially in terms of controlling their execution order) it would be interesting to see if JFX has similar issues once you created a complex class in it with multiple triggers added by different sources...

I think for now I will stop my JFX experimentations, this language has a LOT of potential, but it still lacking in many areas that stops it from real-life use IMHO, namely:
a) lack of usable development tools
b) not very smooth integration with the existing Java functionality (annotations, generics, who knows what else)
c) triggers instead of constructors or actions (sorry, I just don't like this language design approach, period)

I'll stick back to good old "it just works" Java and hope Sun will keep improving JFX to make it actually usable for regular applications. It has a lot of potential, that's true, but Java/Flex/Silverlight killer it is not, at least not yet.

On the positive side, I just read Sun hired one of the creators of GCJ to work with Chris Oliver on future development of the language, so it's good to see they are serious about investing some talented manpower into its futher evolution.