JavaFX 2.0 (a.k.a. What Just Happened to JavaFX Script?)
steveonjava | September 21, 2010There were some huge announcements at JavaOne today for the JavaFX platform. Overall I think the announcements show some very positive momentum for the future of JavaFX and rich client Java, but there were some casualties…
In this blog I will cover the salient bits, but if you would like an opportunity to hear it directly from the JavaFX leadership team in a free event, we will be hosting a JavaFX 2.0 event with Richard Bair and Jai Suri at our next SvJugFX meeting. As usual, the event will be streamed live, and questions can be asked remotely via Google Moderator.
.
The Good Parts:
Java and Alternative JVM Languages
JavaFX has a new API face. All the JavaFX 2.0 APIs will be exposed via Java classes that will make it much easier to integrate Java server and client code. This also opens up some huge possibilities for JVM language integration with JavaFX that Jonathan Giles and I explored in our JavaOne talk today. We did a whirlwind tour through four different JVM languages (Ruby, Clojure, Groovy, and Scala) showing what JavaFX 2.0 code may look like when ported to these different languages.
Here is the full presentation deck:
Which can also be downloaded as a PDF.
Open Source Controls
Thomas Kurian announced a strategy to open source the JavaFX controls going forward. This is a huge move in the right direction for the platform, and will make life for us third-party control developers much better! Even though this is not the full platform open sourcing that I have been petitioning for (thanks for all your support!!!), I will still take some of the credit. 
JavaFX 2.0 Proposed Roadmap
Oracle has published a proposed roadmap for JavaFX 2.0 in the 2011 timeframe. There are some really great things included, many of which I have been campaigning for:
- Multithreading Improvements – The move to Java APIs breaks down some of the barriers to multi-threaded programming that were present with JavaFX. Presumably a similar model to Swing will exist where you can launch worker threads, but still have to do all UI operations on a main event thread.
- Texture Paint – Interesting to see this highlighted, but its use in JavaFX was pioneered by Jeff Friesen and included in JFXtras 0.7.
- Grid Layout Container + CSS – Very good to see that they are taking the Grid Layout and evolving it. The addition of making it accessible from CSS will make it an extremely powerful layout container suitable for multiple uses.
- HD Media – Media seems to be getting a big upgrade, which has been long overdue. This is in addition to other promised improvements in full screen capabilities, media markers, animation synchronization, and low latency audio.
- HTML5 WebView – It is good to see that this is finally getting the attention it deserves. JavaFX is great for dynamic application development, but is not well suited for content presentation. The combination of JavaFX + HTML5 will greatly expand the range of applications that can be developed.
- Controls Galore! – TableView, SplitView, TabView, and Rich Text to name a few. This is a necessity to build robust enterprise applications.
- File (and other) Dialogs – This may seem like a minor point, but is incredibly important for building real applications.
HTML5 Support
Not to be confused with the WebView, there is also a plan for the successor to JavaFX 2.0 (2012 timeframe) to support an alternate HTML5 rendering pipeline. Not many details are available about this yet, but it could be a huge technological breakthrough if they are able to pull it off successfully. The practical applications of being able to deploy your JavaFX application to any HTML5 compliant device is enormous.
.
The Casualties:
JavaFX Script
JavaFX Script was good to us, but it is no longer a go forward technology for Oracle. I am a bit disappointed about this move, because it takes away a lot of the productivity benefits that have made JavaFX code a joy to write. However, many of the promised improvements in JavaFX 2.0 are around language features of JavaFX Script (such as binding and sequences), so hopefully they can maintain some of the benefits.
Richard Bair added a very insightful post on his blog, which goes into more details on the language changes and is well worth a read.
JavaFX Mobile
JavaFX Mobile has not seen a lot of action since JavaOne 2009 and the mobile focus in the keynote was on JavaME and LWUIT. I am still a big fan of the “write once, run anywhere” mantra, and am waiting for this to return to the mobile space. With the proliferation of different mobile programming models (Android, iPhone, WebOS, etc.), whoever solves the mobile cross-platform development problem in a technically solid way will profit immensely.
.
What’s Next?
Now that Oracle is done with their announcements, I have some of my own. If you are at JavaOne, drop by my Wednesday session entitled “JFXtras: JavaFX Controls, Layouts, Services, and More” at 2:15 to hear it firsthand, or wait for my blog post shortly following that.
Thanks for this post Stephen
.
Even everybody thinking the inverse, I liked the changes.
The sad thing is we need to wait a big time to start JavaFX coding again =/
Well that is good news and depressing at the same time. In the future I imagine this will be good all around – especially if they OS the language and the community is able to develop it to support JavaFX 2.0. However, in the meantime it sounds like the current platform for JavaFX is facing at least a short term obsolescence, and there is as of yet no platform to replace it. Anybody invested in JavaFX right now would seem to be put on hold. Is that true?
I hope that Steve’s announcements will shed some light on this.
It really feels like a ‘here we go again moment’, hoping that Oracle will follow through. Given the track record of JavaFx, we’ll be lucky to see JavaFx 2.0 next winter, a very long 15 months out. And when you consider Java is not really a player in the mobile space, less the Android and JME debacles, it’s a double bummer. That said, I like the new direction taken by Oracle with JavaFx and Swing. With so much division in the UI space, there’s always a chance that JavaFx may succeed, especially with support for other popular JVM langauges . I suspect Swing and AWT, though, will slowly fade away, not necessarily a bad thing given their age.
Support Stephen and Jfxtras to continue javafx script! JavaFx 2.0 is too far from us.
Do we know how this JavaFX will be distributed? Is it a part of Java SE? An add-on? If so, how is it licensed? How will it get on users’ desktops?
Thanks,
Cay
Any updates yet?
[...] Speaking at JavaOne was challenging, but fun this year. With the surprise announcements about JavaFX 2.0 there wasn’t a lot of time to respond, but I managed to refocus all my talks in a very short [...]
i am a bit lost here.
I started developing on JavaFX 1.3. What will happen to the FX scripts that are written when the new JavaFX 2.0 arrived? How can i migrate from 1.3 to 2.0? Or some kind souls are already working on the open javafx script compiler
I cannot speak to how easy or hard a migration to JavaFX 2.0 will be (this depends a lot on the new APIs that Oracle is working on, and whether or not they provide a migration tool).
For keeping the JavaFX Script language alive, see my most recent blog post (particularly the parts about Visage): http://steveonjava.com/javaone-enterprise-javafx-and-jfxtras-presentations/
Thanks steve, i look forward to Visage release. There is still hope for those who dive into javafx script
Steve (et al.),
What do you recommend as a choice for GUI work on a brand new Java project?
My app will start out 100% on a Windows desktop, but likely will need to run as an applet (99% sure primarily in browsers on Windows).
Should I use Swing or JavaFX or something else?
thanks
Harry
I definitely can’t recommend Swing, because it is not a go forward UI toolkit for Java.
I would like to recommend JavaFX, but with the pending language change there is a fair amount of risk that you will need to rework your application to run with JavaFX 2.0.
There closest other option is Apache Pivot. It also runs on the JRE, but has much more active development than Swing.
Reply from softwarevisualization:
(reposted by me, because the spam filter kicked it back)
I can recommend Swing. I am not sure what :”no go forward” means, but it’s definitely here to stay on the desktop at least.
Keep in mind that the new UI toolkits like the one that will be in JavaFX are meant to address a certain kind of UI, one that represents the future of UIs such as the kind displayed in the iDevices There are still lots of things that need “regular” UIs such as those found in Netbeans and IntelliJ.
If you’re writing an application with a UI like IntelliJ or Netbean’s , then Swing is your best friend, not least of which is because all Java applications will be able to utilize JavaFX libraries, including the whatever UI components there are. So if you build your application with a clean divide between the model and the UI, in the future you’ll only have to change the UI part of it and then only if you want to.
Swing rocks. If you read the book Filthy Rich Clients, you’ll see that you can really do a virtually anything you can conceive of using just Swing and Java2D.
If you wanted to, you could create your own “future UI” toolkit using just Java2D and Swing.
The only reason that might be a bad idea is because you’d fundamentally be competing with what the JavaFX team are doing right now.
Probably, they’ll do it better. Probably, theirs will integrate in special ways with Netbeans. Certainly, more people will be around that can program to theirs than can program to yours.
But you could do it.
Swing is a fantastic library and very many great applications have been and will be built on it.. It’s also the only game in town right now if you want a WORA application that deals in any real way with text.
> I would like to recommend JavaFX, but with the pending language change there is a fair amount of risk that you will
> need to rework your application to run with JavaFX 2.0.
if oracle ever delivers, and then even if they do, you will be bound to prism, a closed source rendering pipeline. i for one don’t want to be at oracle’s mercy.
> There closest other option is Apache Pivot.
aside from pivot, piccolo2d and zvtm are pretty cool projects, but they represent an entirely new paradigm of thinking about guis which i’m still trying to get my head around. they’re both worth a look though, imho.
I liked these changes.
I think htis as an alternative for Swing + abilities to draw shapes and embedd HTML5 + CSS.
Good job for JavaFX 2.0 team.
I wait for it…………………………………
Thought I’d come back and give people an update…
I’ve been using Java 6 with Swing on two desktop projects for the last couple of months now, since I posted my question.
In both cases it worked out very well. On one small reporting project I used Eclipse 3.5 with hand-coded Swing code for a small number of forms. On the other project, which has many forms, I am (so far) using NetBeans 6.9.1 and building forms with the GUI toolbox.
So far with NetBeans I’ve been able to create any page I needed. Have only encountered a few minor quirks with the GUI tools, not nearly enough to abandon it on that basis alone. Now that my project is getting bigger, it feels a bit sluggish to edit code. Eclipse’s editor seems a bit better, but perhaps if I break up the NetBeans project it will be more responsive. (FYI I’m using a 5-yr old ThinkPad that does need to be replaced.)
I did a demo of the NetBeans app for the client, and explained that I’d decided to go with Swing because of its maturity, stability, and sufficient features to cover our needs. They were happy with that choice and didn’t mention any GUI needs that would push us away from Swing. They also liked the demo very much.
Harry,
I am glad things worked out. Thanks for posting your experience here!
Would be any changes with Clipboard? Eg. clipboard change listener, read from Clipboard and set to clipboard different MIME types at the same time? …