Swing 2.0 is Coming
The biggest announcement - and the biggest surprise for many - of JavaOne 2010 was certainly Oracle's new plans for JavaFX 2.0... or, should we say, Swing 2.0?
The history of JavaFX has been contentious since its beginning, when it was clear that FX was a new toolkit, even a new platform, while most people in the brave Swing community wanted a "Swing 2.0". Well, this is basically what Oracle is planning to deliver with JavaFX 2.0 - minus the ugly legacy of the AWT/Java2D/Swing APIs and architecture. JavaFX 1.x was an ideal replacement for Swing, but ideals don't always work; JavaFX 2.0 will be a more pragmatic attempt at "Swing 2.0". It's just not a drop-in update. Swing code won't be trivial to convert. The announced "plugin3", capable of running Prism, will be 100% free of AWT dependencies. Swing interop will keep requiring using the JavaFX Swing toolkit: the one that's bigger and slower.
Non-evolutionary changes are sometimes necessary. The old UI APIs take my blame for Java's near-death on the desktop & web. Don't dream that the problem was just Sun's neglect, could be fixed by new VM optimizations, deployment improvements, JDK 7's Jigsaw... or the Tooth Fairy. As the partial success of the JDK 6uN project demonstrated once again, no amount of tuning or fixing can save Swing. Even in the Swing community, many wished for a compatibility-breaking Swing 2.0 that would just be similar enough to allow easy migration and interop.
From EJB 3.0 / JPA to the most-wanted JSR-310, experience shows that sometimes enough is enough: the only way for frameworks that didn't work, is the highway. This tells me that some people have double standards when they strongly oppose JavaFX because it's not a smooth update for the existing Swing ecosystem.
R.I.P. JavaFX Script
The JavaFX Script language was the big casualty of the new plan, and I will heartly miss it too; that was quite a fun language to play with. But maybe that's mostly because Java was, and still is outdated. Even Java 8, with lambdas and all, won't be as nice as JavaFX Script (at least for UIs).
Some people will be quite happy creating JavaFX applications with the Java language (even Java 6). Plan B is relying on alternative languages such as JRuby, Groovy, Clojure or Scala; the Scala examples look really good, often hard to distinguish from JavaFX Script. If Scala is extensible enough to build some sugar for JavaFX's binding, I'm sold.
Dropping JavaFX Script has some advantages of performance and footprint. JavaFX 2.0 promises improving on 1.x even with its much bigger feature set. If that looks hard, it's easy to understand: first, Prism is more lightweight than the Swing-compatible toolkit. Second, JavaFX Script tends to produce bytecode that's quite bloated, and a bit slower than equivalent Java code (in one experiment, I got a 4% speedup by simply rewriting a trivial POJO-like class in Java.). These inefficiencies affect both application code and parts of the JavaFX frameworks, originally implemented in JavaFX Script - not the perfect tool for the job. Finally, JavaFX Script was still work in progress: I was hoping that they would add more features, optimizations and refinements... but, time's up.
Some critics complain that JavaFX Script was a wasteful diversion, a science fair experiment. I think it was a quite cool language, and the barrier to entry pretty low to any competent Java programmer that would actually spend a couple days with it. And any new big framework needs many months of experience until you really get the concepts and architecture, understand the tradeoffs and performance aspects, and become capable of writing high-quality code. But language barriers-to-entry are more complex:
- Any JVM framework is better developed in Java. I hate when I read (for example) about Clojure's persistent data structures, as I can't use that in my Java code (at least not in a smooth, natural way). So this great piece of engineering and innovation is locked in the small niche of Clojure fans. Nobody will be motivated to try the full Clojure package after a good experience using its frameworks from Java. From my own small niche of JavaFX Script fans, I didn't mind that others couldn't use JavaFX's awesome frameworks; but this tight coupling clearly didn't do JavaFX any favor. Lesson learned: Write system-level code with the system-level language.
JavaFX Script didn't realy fail, though; it taught us many interesting things, and it paved the way. The future JavaFX 2.0, coded in either "good old Java" or in some high-level DSL-able language like Scala or Groovy, will be a much better system because we have a very clear and concrete vision of the ideal way to do some things. It seems to me that at least part of this technology (the runtime, if not javafxc's code generation) can be reused in a new Java-compatible library they come up with now.
Not a Full Restart
I've seen some skepticism for JavaFX 2.0 plans, claiming that to be a new "full restart" so we'd be heading for another 2-3 years wait until JavaFX is again mature and stable (say, as good as JavaFX 1.3.1 or better). There are some important mistakes here. First, JavaFX 2.0's feature set is much bigger than 1.x. Had Oracle kept the previous course with JavaFX Script, the Roadmap would still be pretty good for next year: new concurrency model; footprint and startup improvements; GA and default Prism; texture paint (thanks!); much expanded CSS support (animations, grid layout); next-gen media stack; WebView (back from the ashes of JWebPane?); HTML DOM and extra browser interop; and a new batch of controls - complex, critical ones like TableView.
Granted, a few items here (Prism, new controls) were originally supposed to GA in 1.4, later this year. The Design Tool was also supposed to hit public beta now. But the major disruption of the new plan is the "black hole" of the next few months, at least until the EA or Beta ships; any code I can write today will have to be ported when 2.0 ships. JavaFX Script will be maintained for some time, but eventually all code that uses the JavaFX Script language and/or the existing APIs will be legacy code (yeah, I see the smiles of Swing fans for the irony).
JavaFX 2.0 is not a full rewrite. The bulk of JavaFX is already written in Java, C/C++ (the runtime has significant native code), or shader language. Only the higher-level public APIs, like UI controls, are written in JavaFX Script (and I expect even these to rely on some Java when it gets though). Oracle will have to rewrite some parts of the runtime, but even that will be partially a port - I don't think Jonathan will ignore all existing code base and design, and write the new Button control from zero, laboriously coming up again with the same rendering and layout algorithms, etc.
Oracle won't start coding all the new stuff next week, when the team resumes from the JavaOne break. It seems to me that they have been working on the new plan for some time now. You can see in the JIRA that the JFXC project looks dead since June when v1.3.1 development finished; 1.3.2 work didn't even start. Oracle has already presented some demos of what JavaFX 2.0 will be, so the new runtime may already have a few months of work behind it - a rough early alpha, at least. Two big-ticket features, the advanced media stack and HTML5 engine, will mostly integrate/wrap third-party projects; and while still not trivial tasks, it seems that work has started quite some time ago in both fronts.
Finally, JavaFX is increasingly less dependent on any programming language. Releases 1.2 and 1.3 started a big push to move as much content as possible to the FXD format, and to web-happy CSS stylesheets. The roadmap for 2.0 further the trend: animation and layout will be scripted by CSS (using standard CSS specs when available). I didn't hear anything about the FXD format, but I think it will also be maintained and improved. So in the end, we don't really lose much of JavaFX Script's nice declarative syntax. Support for these components - from the CSS and FXD parsers / internal metamodel (already implemented in Java), to the NetBeans plugin and Production Suite (already implemented in Java or native code) - should be unaffected by the transition away from JavaFX Script.