Archives for category: JavaOne

At the JavaOne technical keynote just now Richard and Jasper introduced the DukePad – a custom built tablet device powered by a Raspberry Pi and featuring a touch screen, camera, HDMI output, GPIO pins, and more. It is powered with Java and has a custom-built JavaFX user interface.


The DukePad is a Do-It-Yourself, make-at-home tablet computer based on the Raspberry PI and JavaSE Embedded 8. The plans and instructions for building the DukePad are available here, and we’re working with suppliers to make available pre-made kits that can be more easily assembled. The software on the DukePad uses Raspbian Linux as the operating system, and an OSGi-based JavaFX environment. Within this DukePad environment, apps are simple JavaFX OSGi Modules.


Click for bigger image

The DukePad is not a product, it is an open source, freely available set of plans and software for assembling your own tablet using off the shelf components. As such, the quality of the DukePad software environment is demo-quality (although we did strive to write as much real functionality as we could, the realities of demo presentations requires sacrificing time on parts of the applications that are not going to be shown, in favor of smoothing out those parts that will be shown). The code is hosted in the OpenJFX repositories under apps/experiments/DukePad. We hope to see forks of this code (GitHub, BitBucket, whatever you like best) and lots of experimentation and improvement that can be shared.

If you came to JavaOne 2012 or watched they keynote online you would have seen a cool proof of concept we did along with Canoo and Navis. In case you missed it, its on YouTube:

It was built on a early JavaFX prototype with added 3D mesh, Camera and Lighting support. The first public build of JavaFX 8 with the official support for this is now out for you to download, yay!

Download Java 8 EA b77 (including 3D) …

At the moment there is only support for Windows but a OpenGL version for other platforms is being worked on.

For a list of 3D features that are being worked on then check out the Open JFX wiki: – OpenJDK – 3D Features

Here is a very simple example to help you get started:

import javafx.application.Application;
import javafx.scene.*;
import javafx.scene.paint.Color;
import javafx.scene.paint.PhongMaterial;
import javafx.scene.shape.*;
import javafx.stage.Stage;

public class Shapes3DViewer extends Application {
    @Override public void start(Stage stage) {
        PhongMaterial material = new PhongMaterial();
        material.setSpecularColor(Color.rgb(30, 30, 30));

        Shape3D[] meshView = new Shape3D[] {
            new Box(200, 200, 200),
            new Sphere(100),
            new Cylinder(100, 200),

        for (int i=0; i!=3; ++i) {
            meshView[i].setTranslateX((i + 1) * 220);

        PointLight pointLight = new PointLight(Color.ANTIQUEWHITE);

        Group root = new Group(meshView);
        Scene scene = new Scene(root, 800, 800, true);
        scene.setFill(Color.rgb(10, 10, 40));
        scene.setCamera(new PerspectiveCamera(false));

    public static void main(String[] args) {

Simple 3d Example App

I can’t wait to see what sort of cool things you guys will be able to do with it :-)

Now that JavaOne is over and everyone finally has a chance to exhale, it’s time to start blogging about all the stuff we talked about. For my part, I’m hoping to blog about a bunch of stuff that I covered in my two sessions (primarily TableView cell spanning, RangeSlider, Rating, SegmentedButton and whatever else I can find on my machine). For today, lets talk about adding cell spanning support to TableView. Just a quick pro tip: for those of you who just want a jar and don’t care about how cell spanning was developed, you might want to skip to the end of this post…

So, I need to start this post as per usual – this is not a product of Oracle – there is no support contract or guarantee that this code won’t format your hard drive or do something equally nefarious. Please act responsibly for your personal circumstances. Finally, if you do find something wrong (API, documentation, bug, etc), please email me and lets improve it!

With that out of the way, what exactly is cell spanning (and how does it differ from cell merging)? My understanding (and correct me if I’m wrong) is that cell spanning is when the cell at the ‘spanned index’ takes over the full area of the span, whereas in cell merging you essentially take the content of all cells in the span area and merge them into a single cell taking up the area. In other words, the cell will be the same size regardless of whether spanning or merging is used, and it is simply a question of where does the data come from in either case. My preference is cell spanning over cell merging, so that is what I’ve implemented in this blog post.

To make things even clearer, I guess I should clarify what I mean by the ‘spanned index’. What I mean is that, essentially, we continue to layout our TableView in the same way as we always do (TableRow by TableRow (top to bottom), with each TableRow laying out each TableCell within it (left to right)). As we’re doing this layout, we are basically doing what I show in the code fragment below (although I should note this is pseudocode – things are somewhat more complex internally). The ‘spanned index’ is basically the combination of row/column index as we do the layout. In other words, the value in a spanned cell is the row/column index at the ‘top-left’ of the spanned cell area. This means that all other values that are in row/column indices that are overlapped due to a span will be lost. Here’s the pseudocode:

for (int row = 0; row < maxRows; row++) {
    // start laying out a new TableRow.
    // We do this by laying out each column in the row.
    for (int column = 0; column < maxColumns; column++) {
        // laying out each column

Now we’ve covered a bit of theory, I guess we better cover what exactly the end result is. Here’s a few screenshots below – click on them for the full-sized version.


Please excuse the actual data used in the screenshots – I paid precisely zero minutes preparing the demo data – I just used what I had on hand. Clearly what I am doing in the demo data makes no sense for cell spanning – please use your imagination (and ideally send me a better sample data set to use for improved screenshots). :-)

To support cell spanning support, the first new class is the CellSpanTableView. It simply extends TableView and adds support for a SpanModel. SpanModel is defined as such:

public interface SpanModel {
    // cell spanning is only run when isCellSpanEnabled() returns true.
    public boolean isCellSpanEnabled();

    // Returns the CellSpan for the given row/column index.
    public CellSpan getCellSpanAt(int rowIndex, int columnIndex);

The CellSpan class is (presently) quite simple, it is a final class with two immutable fields representing the amount of spanning that should occur in the horizontal and vertical directions. I should note that a rowSpan (or columnSpan) of one simply means that there is no spanning of multiple rows / columns – it is just the default layout. Here it is in its full glory:

public final class CellSpan {
    private final int rowSpan;
    private final int columnSpan;

    public CellSpan(int rowSpan, int columnSpan) {
        this.rowSpan = rowSpan;
        this.columnSpan = columnSpan;

    public int getRowSpan() {
        return rowSpan;

    public int getColumnSpan() {
        return columnSpan;

Therefore, with this API you should do something like the following when creating your own CellSpanTableView instance:

CellSpanTableView cellSpanTableView = ...;

cellSpanTableView.setSpanModel(new SpanModel() {
    private final CellSpan spanTwoRows = new CellSpan(2, 1);

    @Override public CellSpan getCellSpanAt(int rowIndex, int columnIndex) {
        return rowIndex % 3 == 0 && columnIndex == 1 ? spanTwoRows : null;

    @Override public boolean isCellSpanEnabled() {
        return true;

Note that all the magic happens in the getCellSpanAt method – for the given row / column indices, you need to tell the SpanModel what the cell span is. If you return null, you are saying there is no spanning required. In the code above, we span two rows whenever the row index is cleanly divisible by three, and we’re looking at the ‘first’ column. This gets you the result shown in the first screenshot above. I have already heard some requests to improve this API – if you have any strong feelings please let me know!

To achieve the new layout, there is a small number of code changes that need to go into the backend of TableView. Because this post is already quite long I won’t bother to talk about that here – if people are interested I will do another post. Needless to say, the code is included in the links below, but it is definitely a proof of concept, not a final implementation!

Another important point to make is that you should definitely join the cell spanning discussion on Jira at RT-24747 – this is where I would appreciate people post feedback on the API. I already know there are a few things to improve (particularly related to what should be passed to the user in the CellSpan.getCellSpanAt(…) method).

Ok, with all that covered, you can download a zip file that contains both the source and a precompiled jar file. Note that these will only work with the JavaFX 8.0 developer preview releases – they use API that is not available in JavaFX 2.2. It is trivial enough to backport though, and if someone does I will happily host the source code and jar file here.

In summary – lets get the discussion around cell spanning started! I look forward to your comments :-)

Over the last month we built 5 kiosks for JavaOne (1 prototype and 4 production). The idea was to show Java SE Embedded and JavaFX running on a small embedded device as a Kiosk with a great UI to help people plan their JavaOne schedule. One was shown in the Technical Keynote and the 4 production ones were then placed in the Hilton, Parc 55 and Nikko hotels of JavaOne. This is the story of how they were made…


Hello from JavaOne Japan, where Jasper, Jonathan and I find ourselves seated in the opening keynote of the morning. One of the big announcements is the public beta of the JavaFX Scene Builder, our new tool for laying out and creating JavaFX content. The Scene Builder is the start of a more comprehensive RAD (rapid application development) tool for JavaFX, with drag-and-drop GUI building and eventually data binding.

I’ve just returned back from three weeks in the US, and one thing I was asked very frequently during JavaOne was if I’d be making my slides available. It turns out that I don’t even need to upload the slides manually this year – Oracle has put them all up online already. If you want to find slides for (I assume) any of the JavaOne sessions, you can search the content catalog.

However, for those interested in my sessions, the three talks I gave were the following:

  1. UI Controls and Charts: Drag-and-Drop, Filtering, Sorting, Table Hookup with Charts.
    Paru Somashekar and Jonathan Giles.
    Download slides.
  2. JavaFX Datasources: Getting Real-World Data into JavaFX Controls.
    Johan Vos and Jonathan Giles.
    Download slides. For more information, visit the DataFX website.
  3. Custom UI Controls and Charts with JavaFX 2.0.
    Jasper Potts and Jonathan Giles.
    Download slides.

The audio + slides for many of the JavaFX sessions at JavaOne 2011 are available on I have embedded a few we recommend you watch. There will be more arriving on over the next couple weeks as they get processed.

Introduction to JavaFX :: Nicolas Lorain

JavaFX Architecture :: Richard Bair

JavaFX Architecture II :: Richard Bair

The video of JavaFX demo shown in the Java One Keynote is now live for viewing on Oracle Media Network.

Click Me to watch on Oracle Media Network

We had a great time making the demo, I wish to thank Alexander Kouznetsov, Angela Caicedo and Joe Andresen for their help and many late nights working on the demos with me. Nandini Ramani for all her support and letting us steal her office for the week before as a demo war room (hope it doesn’t smell of pizza and coffee any more). We also need to say a huge thank you to Intel who came though at the last minute and provided us two very nice computers to run the demo on, if only they let me keep one 😉

Demo Computers
We were only using one no crazy SLI thing going on, the other was backup just in case.

Alexander and Joe back stage last minute coding, No I meant testing ;-).

Some of the crazy amount of tech back stage.

The keynote room just before doors open.

Joe Andresen, Angela Caicedo, Nandini Ramani and myself (Jasper Potts) on stage just before.

The demo being shown up on the big stage.

Hope you enjoyed the back stage sneak peek, you can see more photos on my flickr.

One of the questions asked in my JavaFX 2.0 blog post, and also at my second JavaFX 2.0 talk on Thursday at JavaOne was around Swing integration for JavaFX 2.0. I wanted to clarify what my current thinking is, and give you a chance to respond.

Edit: If you haven’t yet, please go read Amy’s heartfelt ramble on swing and javafx. She’s says better (and with more authority, having been a critical engineer on AWT, Swing, and JavaFX) than I did.

Over the past several years as I’ve gone on customer visits or to conferences such as Devoxx, I’ve heard repeatedly and clearly that people want to be able to use JavaFX in their existing swing applications. This is obviously important for anybody who has a big, existing swing application or is planning on building a new application in Java and has chosen swing.

In the JavaFX 1.x platform line, we’ve supported the ability to embed Swing components in JavaFX applications. This, however, is not generally that useful for people with existing Swing applications, but rather for people writing new JavaFX applications. This ability has been crucial if they wanted to have rich text or tables or combo boxes. Basically, it acted as a patch to allow JavaFX apps to be built if there weren’t equivalent JavaFX UI Controls yet built. But it wasn’t a bridge per se.

It also isn’t supported in the new Prism pipeline.

However going the other way and allowing JavaFX to be embedded in Swing should be quite feasible, even for the Prism pipeline. Which gets to another point — why having Java APIs for JavaFX was so important.

While on the train to the first Devoxx after JavaFX 1.0 was released, Jasper and I whacked together a quick proof-of-concept implementation of a Swing component that could host a JavaFX Scene. It was subsequently released by Josh Marinacci and some other implementation (I’m not sure if it was ultimately based on what Jasper and I did) was taken and released as part of JFXtras.

The problem with this has been that you cannot reliably modify the JavaFX scene from Java code. This is because the JavaFX Script compiler would produce “obfuscated” java code (this is actually a huge oversimplification and not quite technically accurate, but correct in the essentials). Instead of the mutator for the “x” property being setX, it was set$x. But of course what it was actually called and how it actually worked was subject to change from release to release so you couldn’t dependably talk from Java to JavaFX Script except through interfaces — it was all quite cumbersome.

So to enable developers to embed JavaFX inside Swing is a two part problem: how to do it at a graphics engine level, and provide clean Java APIs for working with JavaFX.

Now that we’ve announced the latter, we’re ready to start working on the former. There are, as you can imagine, a lot of details to sort through. For example, do we force 2D rendering when embedding in Swing? That would certainly be the easiest thing for us to do, but also the least glamourous since you wouldn’t get all that nifty hardware accelerated 3D stuff we’re talking about.

We may instead try to do something along the lines of what Java3D and JOGL did — essentially embed a heavyweight in the swing app. We’ll have to work through problems that may arise when Java2D is using DirectX and JavaFX is using DirectX. We’ll also have a whole pile of thread related issues to sort through.

Speaking of threads, one of the main design goals for JavaFX was to separate the UI thread from the rendering threads. This would allow us to take advantage of all those wonderful cores on machines these days for rendering without slowing down event response times etc. However, Swing was designed such that the UI thread *was* the rendering thread (another problem with immediate mode rendering APIs).

I guess I haven’t quite recovered from JavaOne yet. Rereading this blog post it rambles a bit. So I’d better just stop :-). In Summary, the current plan of record is to work towards allowing developers to put JavaFX content into Swing applications (WebView, Media, scenes, animations, etc), but perhaps not the other way around.