JavaFX links of the week, July 18

A relatively quiet week in the world of JavaFX, but hopefully you can find a link or two of interest! 🙂 Let’s jump into them…

That’s that for another week. As always, feel free to email me links you want included – I appreciate the hints you all give me! Anywho, catch you all again in a weeks time 🙂

Interview with the developers behind GroovyFX

Interview with the developers behind GroovyFX

It was my pleasure to recently come across the GroovyFX project, which works to make building JavaFX 2.0 user interfaces easier and more powerful from the Groovy language. I decided to reach out to the two main developers to see if they would kindly answer some questions relating to this project. Fortunately they agreed, and so here today we have the first interview on FX Experience. Enjoy!

Please introduce yourselves
Jim Clarke: I have been working with JavaFX for several years and am co-author of JavaFX-Developing Rich Internet Applications.
Dean Iverson: I work at the Virginia Tech Transportation Institute where I work with various rich client technologies.  I was an early adopter of JavaFX and a co-author of Pro JavaFX Platform.

(more…)

JavaFX links of the week, July 11

Welcome to another week of JavaFX links! 🙂 Let’s get right into it.

  • There was a new beta build of JavaFX 2.0 put out this week – b34 includes drag and drop support, as well as a Java to JavaScript bridge for WebView among the numerous bug fixes, API tweaks and performance improvements.
  • The Silicon Valley JavaFX Users Group is planning another meeting this week, but I’m not sure what the topic is. It is on Wednesday, July 13, 2011, 6:00 PM at the Oracle Conference Center.
  • Tom Schindl has released e(fx)clipse 0.0.2, which includes improved CSS editing support, as well as the start of better JavaFX integration into Eclipse in the form of JavaFX library specification in projects, a ‘New JavaFX Project’ wizard and JavaDoc integration.
  • jojorabbit4 has updated his ComboBox control to allow for more customisation.
  • Narayan Gopal Maharjan has put up a AutoFill TextBox with support for as-you-type filtering and auto-complete.
  • The GroovyFX project is continuing to get noticed – this week hideaki-t put up a custom browser using GroovyFX to demonstrate the power of GroovyFX and JavaFX.

I hope you all found something useful in this weeks link roundup. Keep up all the hard work folks, and I’ll be back in a weeks time to link to you all over again.

JavaFX links of the week, July 4

July already?! I know I say this often, but man, where does time go?! Also, happy Independence Day to the American readers out there (even though it’s technically not until tomorrow in your part of the world).

There are a heap of links, so lets jump right into it! 🙂

That’s all for another week. I hope you all found something useful! Until next week – keep up the hard work folks 🙂

Worker Threading in JavaFX 2.0

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() {
                    bar.setProgress(counter/1000000.0);
                }
            });
        }
    }
}).start();

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();
bar.progressProperty().bind(task.progressProperty());
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.

(more…)