At last year's JavaOne conference Oracle announced that it would continue to invest in JavaFX, shipping JavaFX 2.0 this year. At part of this, however, it also announced that it would be dropping support for JavaFX Script, replacing it with a new Java API for creating JavaFX applications. That API can also be used from alternative languages such as JRuby, Clojure, Scala and Groovy.

The beta program for JavaFX 2.0 has started, with Early Access releases open to members of the JavaFX Partner Program. A public beta is planned by the end of the first half of 2011. Participants will have the opportunity to provide feedback through multiple channels, including surveys, participation in focus group sessions, and discussions with key members of the JavaFX product team.

InfoQ spoke to Richard Bair, the architect for client software at Oracle, to find out more about the release and future plans.

InfoQ: What are some of the goals you have for the Early Access release?

Our most important goal for the Early Access release is to get feedback on the APIs and implementation as early as possible in our release cycle, so we can make adjustments before reaching our Beta milestone. Assuming we collect a reasonable amount of feedback during the Early Access period, we should be able to deliver an even better initial experience to the wider developer community with the Beta release.

Another goal is to give a head start to companies that have developed applications using previous versions of JavaFX as they begin migrating their applications to JavaFX 2.0.

Also, by releasing builds on a regular cadence, we are making sure the build & release mechanics are all working and in place, which helps with smoother releases down the line.

InfoQ: What is the release schedule? How often will you be updating the builds?

The overall schedule for JavaFX 2.0 can be found at http://javafx.com/roadmap. Starting with the first Early Access build in late January, we have been releasing new builds every week. Currently, builds are only made available to members of the JavaFX Partner Program, as well as individual developers who are very active in the Java developer community (e.g. Java Champions, Java User Group leaders). When we get to our Beta milestone, builds will be made available to a much larger audience through the Oracle Technology Network.

InfoQ: What is missing from the EA release?

There are only two important features that are not in the EA builds yet: the ability to describe a GUI declaratively in markup, and the JavaFX-based browser plug in (which bypasses Swing and AWT entirely for displaying applets).

We have builds available for both Mac OS X and Windows (XP, Vista, 7), though Windows will be the only officially supported platform at this point for our initial release. We will add support for Mac and Linux as soon as we can.

InfoQ: JavaFX has always suffered from limited tools support - particularly the lack of a designer focused environment. Is that something that will be addressed for JavaFX 2?

One of the benefits of relying on Java APIs is that from now on, developers can use their favorite Java IDE to develop JavaFX 2.0 applications. Features such as debugging, profiling, and code completion are available by default, and we are working with the major IDE vendors to provide a tighter integration with the platform.

With JavaFX 2.0 we are initially focusing our efforts at providing the APIs and functionality necessary for rich enterprise applications, as well as rich graphical applications. We are also working on complementary tooling solutions that leverage the designer-developer workflow concept we had introduced with JavaFX 1.x.

InfoQ: Two common problems with Java applets historically have been start-up times and performance. I believe Prism (the hardware-accelerated graphics platform) should make a difference here. Can you explain a little more about this?

There are many factors which go into both startup and runtime performance. Prism is primarily focused on the latter and is designed to take full advantage of the latest graphics hardware in order to accelerate the rendering of scenes (and the ability to mix in 3D content).

With Swing and AWT, the event dispatching thread is responsible both for event dispatch and rendering. With Prism, these tasks may be separated into different threads, enabling us to leverage modern multi-core systems to get more work done in less time. Of course the architecture can be single threaded for different target devices where that is necessary, but on most modern machines separate threads will lead to increased frame rates.

InfoQ: Are there any other specific features planned for Java 7 or Java 8 that will benefit JavaFX?

JavaFX was designed to be amenable to the "lambda" language feature planned for Java SE 8. The current plans and proposals for lambdas favor "single abstract method" interfaces. We have designed the new Java APIs in JavaFX to follow this pattern so that when lambdas become available, they will be natural to use with the JavaFX 2.0 APIs.

Modularity is another feature planned for Java SE 8 that will greatly benefit JavaFX. Modularity promises to help tame deployment (maybe we can finally have a single deployment artifact for Web Start deployment!) and helps improve startup time by reducing the number of classes that have to be loaded. Modularity should also improve startup in a number of other ways such as performing some amount of work at "install time" and caching it rather than having to redo that work every time the application is started.

InfoQ: Dropping support for JavaFX Script means you lose some of the benefits of that language - things like the data flow-style bindings and collection literals. How much of that is supported via the Java API?

One of the most innovative features in JavaFX Script was its support for binding. Exposing it in the language was a particularly powerful concept. Even beyond this, the binding support in JavaFX Script was unique in the range of powerful expressions that were possible and its high performance due to lazy evaluation.

Developers will be happy to learn that we are bringing these important features to JavaFX 2.0. There are both low-level binding APIs (very powerful and flexible, though somewhat verbose) and high-level binding APIs, which use a fluent interface pattern. In addition, we've brought observable collections with us (ObservableList and ObservableMap).

InfoQ: Something that was mentioned at JavaOne was the ability to support rendering to either a native Java 2D / OpenGL / HotSpot VM stack or to a JavaScript / HTML5 / web browser stack from the same API calls. Is this something that will be supported in JavaFX 2?

We have been exploring a number of possible avenues and continue working on this project, which is complementary to, rather than part of JavaFX 2.0.

InfoQ: How much of JavaFX 2 will be released under an open-source license?

At JavaOne we announced that we would be releasing the UI controls under an open source license. I cannot comment on the specific plans, other than to say we are committed to and working on this plan.

InfoQ: Will it be possible to distribute the run-time as part of a stand-alone installer?

Yes! This has been one of the most frequently requested features and I'm very happy to say that moving forward, the JavaFX license is expected to be consistent with the JRE license, which allows such distribution under specific conditions.

InfoQ: Will JavaFX be included as part of Java 7?

JavaFX 2.0 will initially be available as a stand-alone download for users of Java SE 6 and Java SE 7, but we plan to provide a combined Java SE 7 / JavaFX 2.0 bundle soon after.

The JavaFX website should have more information on beta program in due course.

JavaFX Script is also being maintained independently of Oracle through the open source project Visage. We spoke to Stephen Chin about the project last year. Chin is currently working with the Early Access release on a new version of Visage with a view to adding support for the full set of JavaFX 2 APIs. He is also working on Android support, and hopes to have a beta for this available in May.

> JavaFX has always suffered from limited tools support - particularly the lack of a designer focused environment.> "developers can use their favorite Java IDE to develop JavaFX 2.0 applications"

FAIL.

> How much of JavaFX 2 will be released under an open-source license?> "At JavaOne we announced that we would be releasing the UI controls under an open source license."

Good luck at getting this into the various package repositories.

So basically, - they support a shitty language instead of a language targeted at what they wanted to do- they have only a very crappy Swing-like API left- no one (except a few hundred people) are able to test it- they have no initial tool support for it- the software won't be distributed in Linux distributions- the software is non-free- the software is intially not available on any platform except Windows- no direct Web support

They basically did everything wrong which could have been done wrong.Good luck with adoption.

Is Oracle so clueless that they think that any significant developer traction will ever get behind JavaFX?

Oracle (and others) need a whap with the cluestick. Hint, get behind something like Groovy++ and give developers something to get excited about. JavaFX isn't it and never will be something that developers get excited about.

JavaFX will offer:- a Swing-like programming (opposed, here, to the Struts programming),- a HTML+CSS compliant way of programming,- Java as programming language.

... just like GWT!

But questions remain...

* on technical site:Is it planned to display Java components (among other HTML components) inside a page rendered by WebView through WebKit/Java integration ?Or is WebView only able to display HTML components ?

* on marketing side:Is JavaFX going to be released in open source ?what about the JavaFX's future guarantees ?Under which commercial terms JavaFX will be available to the Java community ?