Posted by opinali
on June 11, 2009 at 11:46 AM PDT
A recent blog from Fabrizio discusses usage of JavaFX Script for "controller" code. In my opinion, JavaFX's language doesn't have to be just a GUI DSL, it can reach further than that...
Fabrizio says: "You'd have problems in forcing it to a broader scope than the one it has been designed for." (i.e., GUIs) This may be true, but only because JavaFX Script is still a bit recent in both design and implementation. A few important features are still missing, some only not included due to time/resource constraints because the team's priority is the features to make JavaFX a viable RIA platform. Now that the critical, let's-cross-the-chasm release 1.2 is out, I hope there is more time for enhancements in the "general purpose" area"...
Like this: JFXC-642: Support for maps as a core language construct . One comment even says "We could really do with this for Marina [1.2] release". Unfortunately they didn't, but the bug is now scheduled "After Marina", i.e. the next release; it's one of the top RFEs in my wish list. JavaFX Script's List-like sequences are great, but we really need a Map counterpart, complete with all sorts of high-level syntax sugar (from initialization to powerful comprehensions) and smart javafxc optimizations like flattening, tuning of implementation class choice, sizing, immutable/mutable transitions, conversion from/to compatible Java collections, and other tricks that are already implemented for sequences.
With that and perhaps other few enhancements, JavaFX Script would become just as "complete" as other modern high-level OOPLs. JavaFX Script really could be a very viable candidate to the role of successor or companion to Java as a language for implementation of full Java applications.
Consider this: The Java language has come to a dead-end. The community, apparently, cannot stomach any evolution that would introduce even minimal backwards-compatibility breaking. The full compatibility constraint (both source and binary) makes very hard to introduce any major feature without some big compromise in either functionality, complexity, or interoperability with legacy APIs. Too many people disliked the enhancements of J2SE 5 because of their compatibility compromises (not only generics but also most other features - e.g. the enhanced-for is a timid enhancement compared to JavaFX Script's). Java SE 7 (ok, JDK 7, so far ) is turning out another failure at evolution - Project Coin has nice enhancements, but it could also be renamed to Project Alms, because that's what it is: a charity for the poor souls who insist programming in Java but starve for a more modern and productive language.
Scala might be a great successor of Java. It's reasonably Java-like, well integrated to Java and its libraries, "designed for the JVM", static typed. On top of that, it adds an impressive amount of modernization like type inference, generics (without erasure), functional programming, pattern matching, Actors, and more. In a comment from Gilad Bracha , it's a "tour de force of language design". But Scala is also a significant learning curve to most Java hackers. It's a complex language, even though it avoids any legacy tradeoff. And the Scala team is apparently not yet done with new features, now v2.8 will introduce continuations and more cool stuff. I fear very much that Scala may be doomed to the same fate of Haskell - a language that enchants geekdom with a very elegant design and even a great implementation , but ultimately serves only to influence future designs with more pragmatic constraints. In my dreams, Sun would pick a subset of Scala that any competent Java programmer could master over a weekend, rename it to something like Java 3, and be done with it for the next decade (experts could stick with the full Scala, and that would be a superset of Java 3 so the next migration, or Java/Scala interop, would be even easier).
Groovy has become an impressive system (an even more amazing feat after recovering of a difficult start ), but just like JRuby, Jython and others, it is a dynamic typed language. Most Java programmers will never trade Java for these languages. I don't mean to open this debate here, but if the advocates of dynamic languages think they can turn the tables once their languages are more mature, with better frameworks, compilers, success cases etc., it's not as simple as that. Many developers with a strong education on programming languages, OO and related subjects, have a firm, well-founded preference for static typing, and can only be convinced to move to languages with even more (or better) of that, like Scala. Speaking for myself, the single feature of dynamic languages that's worth anything IMHO is powerful metaprogramming features (as more superficial features like "less typing for variable declarations" are largely obsolete in modern languages - with a "pure" typesystem, strong generics, and type inference). Well, nothing is perfect, and I'll take the safety/performance/convenience of static typing over a MOP any day. (Optional static typing like Groovy's doesn't cut it, because I don't see how this can go together with some modern features like advanced type inference.) OK, so I didn't resist and I did open that debate just a little; but the point is, most developers prefer static typing; this just won't change next week; and it's not even a Java-specific trait resulting from Sun's designs. Other dominant languages, from C/C++ to C#, SQL, and any decent XML-based language (with a strict schema), are all static typed; C# is also evolving in the same general direction of Scala. Having said all that, the Java platform is welcoming dynamic languages; as an advocate of Java[-the-platform] I am very enthusiastic and supportive of improvements from javax.script to invokedynamic and other enhancements in JDK 7 . Some people prefer dynamic languages, we can agree to disagree, to each his own etc. - I even make limited use of those languages in niche needs. And the bottom line is, if these languages run great in the JVM, it's a win-win for the whole ecosystem around Java.
Now let's close this digression and turn back to JavaFX Script. If you're already up to speed with JavaFX programming (and you value higher-level languages even with some small tradeoff in performance or access to legacy APIs), what are your thoughts about using this language as a general replacement of Java? Let's say, to program the persistent entities and business logic, packed in some Java EE EAR, "behind" the GUI? Which features are missing? (Suppose, of course, that somebody will write lightweight and convenient JavaFX Script APIs wrapping all the Java SE/EE APIs you need; or perhaps even better APIs that take full advantage of JavaFX Script, ignoring old cruft.) Beyond a map type, my next obvious pick is Java's Annotations, essential to support most modern SE/EE APIs "“ and that's a pretty small change as javafxc could basically "pass" the annotations to the resulting Java artifacts. Notice that I'm not proposing that JavaFX Script can be a full replacement for Java; just a "higher-level companion" for application-level coding. it's OK to need Java for "system-level" tasks, from stuff that needs low-level typesystem features for performance, to ugly APIs that may be impossible to make much simpler with a thin wrapper like the full extent of Java Reflection APIs.
P.S.: JavaFX Script's binding feature, its biggest claim to fame, is most certainly NOT a DSL-esque construct that's "only good for GUIs". If you think that, it's like thinking that "generics are only good for Collections" or "closures are only good for event handling plus a better foreach" (I've heard/read such opinions from many, many developers who have shallow knowledge of these features). Binding is a very general and powerful construct. It remembers me of my study of Constraint Satisfaction Programming while doing my MSc ten years ago. Binding is more limited than CSP, it just implements the facility of automatic propagation of dependent assignments (but it's very good at that, including minimal reevaluation: e.g., x = bind y + f(z) doesn't invoke f(z) again when only y changed; with sequence binding, only affected slices are recomputed). But this is already very powerful. Just like those pure and famous OO or functional languages that didn't succeed in the real world, CSP didn't enter so far in the mainstream. (To be fair they didn't even try - only academic attempts were made, like Kaleidoscope - now completely forgotten). But this research influenced more traditional systems, like JavaFX Script, to make a more pragmatic "baby step" that is still extremely useful.