Archives for category: General

With the end of 2011 nearing, I thought it would be a good time look back on what has happened in the world of JavaFX this year…


With JavaFX 2.0.2, we’ve included support for interop with SWT in the same way that we support interop with Swing. That is, you can embed JavaFX within your SWT applications! Although e(fx)clipse has been doing this for a little while by embedding FX -> Swing -> SWT, you can now skip the intermediate embedding into Swing and just go straight to SWT. Because FX and SWT share the same basic threading model, this is really easy to do.


One of the projects I worked on leading up to JavaOne 2011 was the DataFX project, which, as I wrote on the website, “is an open source project that intends to make retrieving, massaging, populating, viewing, and editing data in JavaFX UI controls easier. It’s all that boring kludge work you have to do between getting user requirements and delivering a rich user experience.”

DataFX is a project Johan Vos and I have been working on for many months now, and it has gone through a number of iterations in that time. At JavaOne 2011 we put out a first release (let’s call it version 0.0.1 for lack of an official version number), and today I want to briefly introduce it for those of you who didn’t attend JavaOne. However, even if you didn’t attend JavaOne, we’ve put the slides online.

To be very clear, DataFX is not an Oracle project! Johan and I both developed this in our own time, and it does not necessarily represent the future plans of the official JavaFX project. This project was built to make many of the UI controls I develop easier to work with by filling in the gaps as of the current JavaFX 2.0 release. Oracle may or may not have future plans in the same area as DataFX, but for now DataFX exists to fill the gap. For more details, check out the DataFX FAQ.

To make things easier to understand let’s conceptually split DataFX into two sub-projects which attack a common problem from two different angles.


I was just given notice that we were allowed to share an internal FXML document originally written by Greg Brown, a member of the JavaFX controls team. What follows is a painfully slow (and very labour intensive!) PDF to HTML conversion We’ve updated the document, and instead of re-translating it every time, I will now just be posting the PDF file directly. If you find any mistakes, please leave a comment (or email me), and I’ll update the document. I also have to add the normal disclaimers: this is a draft document, and it is likely that it may change leading up to the GA release of JavaFX 2.0. With that out of the way, read on and enjoy! :-)

Download the latest 'Introducing FXML' document

In case you’re wondering what FXML is, FXML is a scriptable, XML-based markup language for constructing Java object graphs. It provides a convenient alternative to constructing such graphs in procedural code, and is ideally suited to defining the user interface of a JavaFX application, since the hierarchical structure of an XML document closely parallels the structure of the JavaFX scene graph.

For the past couple of years the industry has continued to follow Moore’s Law by shifting from CPU clock speed to increasing the number of cores and threads per core. Even cell phones are getting multiple cores these days! Taking advantage of all these cores and threads is one of the hallmarks of modern GUI platforms. But all this concurrency brings a multitude of problems to the application developer, not least of which is that writing multithreaded applications is hard!

In designing JavaFX 2.0, we of course needed to address both how the scene graph would behave in the presence of multiple threads, and how developers could effectively do work in background threads and keep the UI responsive. In short, the JavaFX scene graph, like all other mainstream GUI toolkits, is not thread-safe and must be accessed and manipulated from the UI thread (call the FX Application thread). Swing and AWT had the same basic policy (only work with Swing or AWT from the Event Dispatching Thread), as did SWT (only interact with SWT resources and components from the thread that owns them), as do all other major toolkits (JavaScript / HTML included).

The most common problem with this design is that developers who do not do work on background threads invariably create unresponsive applications, since this long lived (potentially blocking) code happens on the same thread that processes user events. That is, while your long lived operation is running, no mouse or key events are being processed, which leads to an application that appears to “hang”.

Further, actually writing well behaved background workers is difficult and error prone. Even if you create a Runnable and create a Thread and do your long-lived work in that background thread, at some point you need to communicate back to the UI, either with the result of the long-lived computation, or by communicating to a ProgressIndicator of some kind what the progress of this long-lived operation is. This is error prone, because you must be sure to communicate with the UI by putting events back onto the event queue (using Platform.runLater, the equivalent of Swing’s invokeLater).

Note: This article is a sneak peek at a new API which is coming in the next couple of weeks, but is not currently available in the Beta builds! There is a deprecated Task class in the beta builds which will be removed and replaced with the one detailed here.

Suppose we have a simple background thread which just counts from 0 to 1 million. Suppose I have a single ProgressBar, and that I need to update the progress of this ProgressBar as the counter runs. A naive implementation might look like this:

final ProgressBar bar = new ProgressBar();
new Thread(new Runnable() {
    @Override public void run() {
        for (int i=1; i<=1000000; i++) {
            final int counter = i;
            Platform.runLater(new Runnable() {
                @Override public void run() {

This is a hideous hunk of code, a crime against nature (and programming in general). First, you’ll lose brain cells just looking at this double nesting of Runnables. Second, it is going to swamp the event queue with little Runnables — a million of them in fact. Clearly, we needed some API to make it easier to write background workers which then communicate back with the UI.

Java comes with a very complete set of concurrency libraries in the java.util.concurrent package. We wanted to leverage what was already defined in Java, but we needed to extend these APIs to take into account the FX Application thread and the constraints that GUI programmers are under. The javafx.concurrent package contains three core files: Worker, Task, and Service.

Before diving into the rather verbose description (taken from the proposed javadocs) for Worker, Task, and Service I wanted to cut to the chase and show some examples. The first key thing to mention, is that Worker is an interface that is implemented by both Task and Service, and which adds the sort of convenience API necessary for a background worker that is useful for communicating back with a UI. Second, Task extends from java.util.concurrent.FutureTask. This means that a Task can very cleanly fit into the concurrent libraries. As you may know, FutureTask implements Runnable, and can be passed to an Executor’s execute() method.

So real quick, here is the same example as above, but it suffers from none of the flaws exhibited in the naive implementation.

Task task = new Task<Void>() {
    @Override public Void run() {
        static final int max = 1000000;
        for (int i=1; i<=max; i++) {
            updateProgress(i, max);
        return null;
ProgressBar bar = new ProgressBar();
new Thread(task).start();

In this example, I first create my Task. The task implementation just does its work, invoking the protected updateProgress method defined on Task, which ends up updating progress, totalWork, and workDone properties on the Task. I then create my ProgressBar and bind its progress property with the progress property of the Task. Then, since Task is a Runnable, I can just create a new Thread passing it the Task and then start the Thread.

Alternatively, I could create an Executor or ExecutorService (such as a ThreadPoolExecutorService) and execute the task using the ExecutorService.


I was just going through the bug database and realized that, to my knowledge, we’ve never actually told people what the code names are for our releases, and that that is pretty useful to know when filing bugs. Ever since JavaFX 1.0 we’ve used street or area names from San Francisco as our code names. Honestly I can’t remember the 1.0 code name anymore. 1.2 was called “Marina”, 1.3 was “SoMa” (South of Market).

This release, 2.0, is called “Presidio”, and the next major release is called “Lombard”. So when you see that your issue is targeted at one of these, you know what we’re taking about! If it remains “untargeted”, then it has gone into the pool from which we draw features for future releases, but may not be targeted to a specific release until later in the planning cycle.

Something that you see more and more with client applications at the moment is embedded map components. This blog will show you how to embed Google, Yahoo or Bing maps in your JavaFX application.

Google Maps in JavaFX 2.0

Download a copy of the application and try it out. The jar file is linked below, just download it and double click. This requires you to have the JavaFX 2.0 beta runtime installed.

Download double clickable jar


We did a complete rewrite of charts in JavaFX 2.0 to add cool features like:

  • Dynamic Data Support
  • Animation
  • Auto Ranging
  • CSS Styling

There is a sample application called “Chart Sampler” that ships with JavaFX 2.0 Beta that shows some of what can be done with the new charts. Here are a few screen shots to tempt you to go and check it out :-)


For months and months we’ve been focused solely on the mechanics of building a platform — API design, writing tests, fixing bugs, use cases, features, documentation etc — and with the release of the beta the #1 question on everyone’s mind is, “Is JavaFX 2.0 cross platform?!”. That the beta is initially a windows-only beta has apparently stirred up a fair amount of concern. Shockingly, some people have even asked whether we ever intend to be cross platform. I can say definitively “Yes, of course!”. It would be quite illogical for any platform released by the Java team to not be cross platform. And even more so for the Java team to release a platform which had no intention of being cross platform while also purporting that the said platform was to be the next generation Java rich client platform.

We absolutely will be targeting a whole host of different platforms, not even just the big three (Mac, Linux, Windows). The value of the Java platform is in the fact that you can write across multiple operating systems and devices.

Now, somewhat like Apple, Oracle doesn’t tend to make premature announcements. I cannot at this time comment on when support for different platforms will be available, but hope to comment when such announcements have been made through the official channels. I know that this form of communication strategy leaves people to their own imagination which, as often as not, seems to be rather pessimistic in nature :-). So, to help provide some guidance here, I’d just like to say:

JavaFX will be cross platform.

Great news today, the public Beta for JavaFX 2.0 has been released! The beta includes a handful of samples, including Ensemble which is the sampler for JavaFX and will be beefed up over time to include tips and tricks and other such things. There is also javadoc (though, beware, there are still JavaFX Script examples. The docs for new code is better than old code). If you find bugs, submit them to the JavaFX JIRA bug tracker.

There is a lot of great stuff in this release, including binding, observable collections, sortable and filterable observable lists, many more UI controls, enhanced animation support including for game loops (AnimationTimer), properties (observable!), and more. There are a few things we’re still adding (including some important things!), but for the most part, the features are all there and functional, so go try them out! Please do file bugs, write blogs, and let us know what you think of the APIs. Things are definitely more verbose in Java than they were in JavaFX Script, though in large part this will be solved with lambda’s in Java 8.

Especially, if you have use cases that our APIs prohibit (as opposed to API we just need to add) please please please! file these in JIRA! The reason we’ve released the beta is to get exactly this kind of feedback. API is forever, so all the feedback you have on the API please file, and the sooner the better!