Sun just announced their entry into the Rich Internet Application horse race. JavaFX is essentially a domain-specific language for GUI construction layered on top of Swing. I rather like it. It reminds me of Tcl/Tk â€“ light-weight, pragmatic, declarative rather than procedural. Sun must have been so desperate to not be left behind that they didn’t have time to over-design it to be all things to all people. If Sun can refrain from ruining it, it might turn out really nicely. Unfortunately it is not yet usable enough for my work.
The only description of the language available is this, which is unfortunately only a partial overview. The two key features of the language are an entity-relationship data model, and functional data-flow. First the data model. All variables are sequence-valued: a sequence of 0 or more values. The 0-length sequence is called ‘null’. You can declare a variable’s cardinality like in UML with ? (null allowed), + (one or more), and * (zero or more). [Why aren’t there cardinalities for at most one and exactly one?]
These sequences are called arrays, an unfortunate choice of name, because they are very different from conventional arrays. They are more like lists in a pure functional language: immutable sequences of values. But arrays cannot be nested, so Strings cannot be treated as arrays of Chars, which is what they truly are. This difficulty is one of the main reasons I have not gone with sequence values in Subtext despite their benefits. I think it is a gutsy move to go with sequence-valued variables, and I look forward to seeing how it works out.
There is a JSON-like syntax for object creation using attribute-value pairs without having to write procedural code. Variables are statically typed, with inferred types. All array elements must be of the same type. In the examples I see anonymous functions as values, but there is no discussion of whether there are closures or higher-order types.
Class fields are called attributes, and, like variables, are sequence-valued. Further, an inverse attribute on another class can be declared, just as in UML attributes. Changes to an attribute get automatically reflected in its inverse. The result is that FX classes form a standard entity-relationship model as used in many modeling languages. That is also a goal of Subtext, and I am a little jealous. Rather than define getters and setters, you define triggers as in a relational database.
The key to adding UI reactivity is incrementally evaluated functional data flow. You can bind one attribute to a function calculated on other attributes, and whenever those inputs change the function will be incrementally re-executed to calculate a new result. This is a generalization of the standard “binding” facility present in many GUI toolkits. Subtext is based on the same idea, generalized to support all forms of computation. In some cases, such as input fields, binding can be bidirectional, but no details of how that works are provided. That is a hard problem in general. Animation is achieved by defining a time-varying value which can be bound to any attribute.
FX does general queries over products of arrays, and supposedly evaluates them incrementally as well. There is no mention of mapping database queries into an array, but that is an obvious move to make. Thinking even further ahead, all those tools that generate Java from UML would be more naturally suited to FX’s data model. If it catches on, FX might evolve into an interesting hybrid between a modeling language and an implementation language. That is also where Subtext may be heading.
There is language support for AWT’s threading model. FX operations run in the AWT event thread, except within the “do” construct, which spawns a synchronous activity in a background thread while still servicing AWT events. “do later” spawns asynchronous threads. Such background activity can only use Java objects, not FX objects, which seems a rather coarse constraint.
FX wraps the major Swing components, and supports SVG-like graphics primitives. In general, FX has free access to Java classes and libraries. It is unclear how much access Java has to FX constructs. It seems likely that FX and Java are not full peers, but rather that FX takes over managing the entire UI while Java does the model objects behind it, and the Swing components in front of it. I believe FX can only succeed if it manages to totally hide Swing from application builders. Even then it will depend on the visual quality of the Swing components, which historically has been industry-lagging.
The current implementation of FX is fully interpreted, and fairly slow. No mention of a debugger, which would be complicated by the incremental (and sometimes lazy) data-flow semantics.
All in all an interesting language with a novel combination of features, very well suited to its target domain of GUI construction. I look forward to following its progress, and I wish I could actually use it today.