Adam Bien's Weblog

Monday Feb 14, 2011

Hello JavaFX 2! - Back To Java

In contrary to JavaFX 1.X, JavaFX 2 is pure Java:

package com.abien.hello;

import javafx.application.Application;
import javafx.application.Launcher;
import javafx.collections.Sequence;
import javafx.scene.Group;
import javafx.scene.Node;
import javafx.scene.Scene;
import javafx.scene.control.Label;
import javafx.stage.Stage;

public class Main extends Application{

    @Override public void start() {
        Stage stage = new Stage();
        stage.setTitle("Hello Java FX");

        Group root = new Group();
        Scene scene = new Scene(root,80,20);

        Sequence children = root.getChildren();
        children.add(new Label("Hello Java FX 2"));


    public static void main(String[] args) {
        Launcher.launch(Main.class, args);

Java FX 2 application can be compiled having jfxrt.jar in the classpath and launched like any other Java application: java -cp javafx-sdk2.0-ea/rt/jfxrt.jar com.abien.hello.Main
Even in the case of the preview the startup performance is <1 sec and significantly faster, than 1.X version.
This post is based on Java FX 2 Early Access - the API and runtime can change any time.
Sees official JavaFX roadmap for more details.

NEW: Java EE 7 Testing and Quality Workshop

A book about rethinking Java EE Patterns


So java fx will be the new swing?
Will it replace swing or complete it?

Posted by Loic Descotte on February 14, 2011 at 12:35 PM CET #

Is this going to be open or closed source?


Posted by Ian Smith on February 14, 2011 at 12:59 PM CET #


I'm a freelancer - completely independent on Oracle - so don't expect any official answer from me.

I think JavaFX 2 will complement Swing and will be also interoperable - much better, than JavaFX 1.3



Posted by on February 14, 2011 at 01:08 PM CET #


not sure, whether it will be entirely open source, but it will be more open, that at the Sun time.



Posted by on February 14, 2011 at 01:10 PM CET #

I'm mostly interested in web features.
Is WebView and etc. in this release included? How good is it? Can you show us a screenshot?


Posted by ilhami visne on February 14, 2011 at 04:32 PM CET #


stay tuned - still investigating :-)



Posted by on February 14, 2011 at 04:55 PM CET #

So the JavaFX Script is going to be removed? And so we have the same verbosity of Java- setters and getters.

Posted by Mohamed Sanaulla on February 14, 2011 at 05:09 PM CET #


unfortunately - yes. I really like Java FX Script....

But: for the adoption the current approach is far better.



Posted by on February 14, 2011 at 05:15 PM CET #

Hi Adam,

Where can we use JAVA FX , is that used in J2ME world ?


Posted by Javin Paul @ Tibco RV Tutorial on February 14, 2011 at 05:47 PM CET #

where can I download JavaFX2 pre release? :D

Posted by Eko Kurniawan Khannedy on February 14, 2011 at 06:39 PM CET #

Great! I'm waiting for JavaFX 2.0 since the announcement that it will not be an Script language anymore! but just pure Java. This will improve Java on and bring in it to the modern desktop.

Posted by Xavier on February 14, 2011 at 06:50 PM CET #

I can't really see a big difference between Swing and JavaFX in your code sample.

I thought JavaFX was also intended to make GUI development less cumbersome?

Posted by Steve on February 14, 2011 at 06:51 PM CET #

@Eko, plus one on that.

Posted by Alosh on February 14, 2011 at 07:34 PM CET #

please, publish example like this

this is example for JavaFX v1.0

Posted by surikov on February 14, 2011 at 09:33 PM CET #

It always worried the amount of lines to get something visible in Swing.

Of course, after knowing Swing you just don't realize it but it requires a lot of knowledge and fails silently if done wrong as most of the time it's just a problem of misunderstanding the API.

The last 3 lines worry me:

Sequence children = root.getChildren();
children.add(new Label("Hello Java FX 2"));

getChildren() followed by add() and then the method I hate the most, setVisible().

Why is it that setVisible(true) must be called? Wouldn't it be possible to avoid it from inside the API?

Posted by Tomás Lázaro on February 15, 2011 at 12:32 AM CET #

You could collapse those three lines slightly by merging the first and the second line:

This is actually something that I've been discussing internally - whether we should require all users to call getChildren(), or whether there should be convenience methods to add/set/remove directly on the node. Both approaches have positives and negatives, and your feedback is appreciated.

Regarding setVisible - well, that ain't going anywhere. There is no way JavaFX can implicitly know when you want to show or hide something. setVisible is your way of telling JavaFX that the stage is built, and should be shown to the user now.

Posted by Jonathan Giles on February 15, 2011 at 12:38 AM CET #

Adding to Tomás Lázaro concerns, if root is already a group, why do I have to call getChildren() ?, why not just add?, I mean, root.add(). I would understand the getChildren method if I would want to do something with its current children, but not to modify the group itself.
I think the api should be concise, this kind of unnecessary wording really hurts it.

Posted by rcano on February 15, 2011 at 12:45 AM CET #

A Group has children, which are accessed via the getChildren() method. This method returns a sequence of the nodes contained within this Group. You add, remove, and generally modify all children of the group through this sequence.

The beauty of this approach is that the method returns a Sequence, which is immediately observable and bindable, and which provides a consistent API across JavaFX for managing the scenegraph hierarchy. There are no additional methods for add/remove/set/addAll/removeAll/setAll/etc/etc/etc that clog up every single Node.

If we were to add API for add/set/remove, then it would purely be as a shortcut to the equivalent methods on getChildren().

It can be a little odd to wrap your head around it, which is why I said earlier that I am discussing providing these short cut methods. Whether they are added to JavaFX 2.0 is a function of the feedback we get in the coming months as the EA and beta releases proceed.

I should note, however, that after having used this API for the last few months, I find it to actually be pretty decent. I would recommend you play with the API as it stands when you get access to JavaFX 2.0, and then provide your thoughts via the JavaFX Jira dashboard here:

Posted by Jonathan Giles on February 15, 2011 at 01:09 AM CET #

So the declarative nature is lost. This is just another Java API now. Why doesn't Oracle make a decent DSL, at least?

Posted by goddard on February 15, 2011 at 09:16 AM CET #

There is the Visage project that plans to retain the JavaFX Script declarative nature, whilst using the latest JavaFX 2.0 API and features under the hood.

There is also the option of using any other JVM language to write your user interface in, whilst using the JavaFX 2.0 toolkit. This means people that love Groovy, Scala, Clojure, Jython, JRuby, etc , etc can all work in their preferred languages.

I believe this is certainly a better option than what we had in the past where you had to write in the JavaFX Script DSL, which many people refused to learn.

Posted by Jonathan Giles on February 15, 2011 at 10:55 AM CET #

" whether we should require all users to call getChildren(), or whether there should be convenience methods to add/set/remove directly on the node"

I can't imagine a single reason for the "getChildren()"-approach. It lacks proper encapsulation, and makes it impossible for the node to control its own sequence.

There are loads of reasons though to hide the internal data structure from the user: Be it a later change of implementation (think maps, sets, etc, for optimization or convenience reasons like finding a node by an identifier), be it proper locking (ui-tree-locks) or plain control over the list's lifecycle. If you need to provide the capability to iterate over the children, why not publish an iterator instead?

With Lambdas on the horizon and several SAM-Type-based utils in place (think apache.commons.collections - Transformer and Predicates, think Hamcrest matchers and similar), I don't think there is any reason left to publish a mutable(!) collection.
Better provide some ready made SAM-Types for common operations.

An idea would be something that can be used like this:
List<Node> selected =
node.copyChildrenTo(Node.matchAll(), new ArrayList<Node>());

A style that is pretty ready for Lambdas and favors code-reuse. These SAM-Types could be used throughout the whole API and if the user rolls his own, could use them aswell, whenever the state a node is altered or evaluated - also in his own code.

Mind you're producing framework-code made for long-term usage.
You should not sacrifice some lines of gluecode to proper encapsulation, All you'd get was a maintainance nightmare.

Posted by Wanja on February 15, 2011 at 11:59 AM CET #


please see my JIRA Feature request regarding fluent interface - and the proposed code snippet,

thanks for commenting!,


Posted by on February 15, 2011 at 12:58 PM CET #


btw. kudos to all JavaFX engineers - a huge step forward.



Posted by on February 15, 2011 at 01:00 PM CET #

I like your suggestion on Jira. For those with Jira access to internal issues, it can be seen at RT-11183.

Thanks for your feedback. I've brought this issue up again and I'll be sure to make your thoughts heard.

Posted by Jonathan Giles on February 15, 2011 at 02:24 PM CET #

Hello , will there still be presence of binding feature in javafx 2.0??

Posted by Narayan Gopal on February 15, 2011 at 03:03 PM CET #


binding is already included in Java FX 2.



Posted by on February 15, 2011 at 03:41 PM CET #

Will JavaFX remain as another runtime, or a library?

Posted by goddard on February 15, 2011 at 03:51 PM CET #

Cool. I am waitung for your JavaFx book.

Posted by on February 15, 2011 at 03:54 PM CET #

The only comment I will make is: take your time. I would much rather you do it right than have you freeze the API too early and end up with a repeat of past disasters.

Please reserve the right to change the API for at least one year after it is officially published. Let the API evolve until you achieve an organic maturity (not mandated by a fixed schedule) and then you can stamp the API as frozen. I suggest doing this on a per-class basis.

Posted by Gili on February 15, 2011 at 05:50 PM CET #

Hi @Wanja,

I just wanted to clear up a misconception here. Having getChildren() return a Sequence is absolutely *in no way* breaking encapsulation. Sequence is an interface, not a concrete class. It extends ObservableList which extends List. So Sequence is in fact carrying only the minimal semantic information necessary for any representation of an ordered observable list (which is exactly what the "children" property is). You could just as easily have that Sequence backed by an ArrayList as any type of concurrent queue, linked list, or custom data structure. Further, lambdas will come with support for using lambdas over collections, so by exposing a List we will get all that support for free. getChildren hides the storage and creation of the sequence. So suggesting that we have broken encapsulation here is clearly incorrect.

Posted by Richard Bair on February 15, 2011 at 06:59 PM CET #

Hi Adam

Is also already implemented something like triggers on javaFX 2.0?
I used this futre a few time in my code and wanna now if i have to rewrite the old code? And will be also an converter from the skript language to the new API?

Posted by Markus on February 15, 2011 at 08:37 PM CET #

When I complained about getChildren() and add() it was regarding the usage, not the lines it would require. I understand that getChildren() has it's reason.

Regarding setVisible(true) I was thinking more like that should be the default and if you would like it not to be visible you should do setVisible(false) and then turn it on when appropriate. That is way more natural. Unless of course the are side effects associated with setVisible that makes it impossible to be implicitly set to 'true' by default.

Posted by Tomás Lázaro on February 15, 2011 at 09:41 PM CET #


Scala can make a nice DSL from what's already available in JDK. No need to have another runtime. Oracle should bury it, like the other projects. This one would deserve it, at least :P

Posted by goddard on February 15, 2011 at 11:12 PM CET #

Woooooowwwwww !!!!!

Great great news !! I can wait to start coding in javafx2 !!! that's what I've been waiting for in the past few years !!! thanks for sharing Adam, when it gets light sure Adam can show us a nice example on javafx and EJBx.x !!!!!

Posted by Aleix on February 15, 2011 at 11:35 PM CET #


as long as the Groovy / Scala DSL would look like Java FX Script - it would be absolutely o.k. :-)
Seriously: such a DSL should be shipped with JavaFX in the future. I don't think, that it is viable to expect from JavaFX users to develop in every project an own DSL...

JavaFX Script was very nice - the tooling was bad... The support in NetBeans for Groovy, Ruby or JavaScript was better than JavaFX Script :-)



Posted by on February 16, 2011 at 12:24 AM CET #


indeed - a lean EJB 3.1+ with JAX-RS would be a perfect endpoint for JavaFX 2 :-)



Posted by on February 16, 2011 at 12:26 AM CET #


Do you happen to know anything about property binding API? Is it part of javaFX 2.0? Do you have an example of it's usage at hand?

Thanks, Peter

Posted by Peter on February 16, 2011 at 02:06 AM CET #

Why don't you separate UI construction to external resource file instead of Java code? By doing that, we can still separate concerns of programmer and designer and ease tool support.

Posted by Kiju on February 16, 2011 at 04:41 AM CET #

That is something being actively considered now, and we have a few approaches under consideration.

Posted by Jonathan Giles on February 16, 2011 at 05:20 AM CET #

JavaFX 1.3 can wrap Swing components. We're told there'll be a Swing component that can display a JavaFX 2.0 scene. Has anyone tested whether this lets you successfully show JavaFX 2.0 scenes within a 1.3 app?

(Thinking about phased migration routes for old 1.3 code)

Posted by William Billingsley on February 16, 2011 at 05:25 AM CET #

will it run on android?

Posted by superdude on February 16, 2011 at 08:11 AM CET #

@Richard: Thanks for your clarification about the Sequence-interface. Just the fact that it's an interface doesn't secure encapsulation though. It depends on which object is published by the getter.

Have this example:
class Foo{
private List<Bar> bars;

List<Bar> getBars(){return bars;}
is a breach of encapsulation.

class Foo {
private GuardedList bars;

List<Bar> getBars(){return bars;}

private class GuardedList implements List<Bar>{
public void add(Bar o){

is not.

I should have thought about this possibility in my criticism.

Still I do think, regarding Demeter's Law, that it's in general better to provide access through the Node itself. Makes the code less brittle in my opinion, yes: It requires boilerplate for delegation.

Posted by Wanja on February 16, 2011 at 10:29 AM CET #


cool, no 10s of closing brackets at the end of even the most trivial of code example <g>

Without more than those handful of lines, though, the most obvious of those to pick at are the - already extensively criticized -


that rings a bell, doesn't it:


The Swing team took several years to recede and allow the "natural" frame.add(...), hope the fx team is quicker :-)

Another track: Application looks similar to jsr296 (or was it 295, forgot) - any relation? And if so/or not, how far away?


Posted by Kleopatra on February 16, 2011 at 12:45 PM CET #

I've written some Code with JavaFX 1.1 in 2009 and had to invest some time to make the code run with newer versions. The code is all Java FX Script and I will defenitely not port it to Java but throw away. Allthough there is much to complain about Java FX Script, I still like the scripting much more than I do like to do the same in Java. I've been following the discussion for a while now and I see more and more of the old mistakes done with Swing pop up in Java FX. What I would like to see instead is fixing the design flaws of the scene graph. Neither Jazz nor Piccolo had a good design and the same applies to the scene graph at its current state. I am disappointed. I will not continue in using Java FX at all.

Posted by want to stay anonymous on February 16, 2011 at 02:38 PM CET #

Hello I'm wondering if javafx 2.0 has something touched at android or mobile phones!!


Posted by Narayan Gopal on February 16, 2011 at 03:17 PM CET #

Hi Adam

Is also already implemented something like triggers/bind on javaFX 2.0?
I used this futre many time in my code and wanna now if i have to rewrite the old code?

Posted by Raffaele on February 16, 2011 at 06:02 PM CET #

Well, I guess it will have to be Visage then.

Java on the desktop, don't make me laugh!

Posted by Maya Incaand on February 16, 2011 at 07:54 PM CET #

Looks amazing!!!

Hope JavaFX2.0 will change the disposition on desktop!

Posted by anatolnsk on February 17, 2011 at 11:38 AM CET #

Original JavaFX was innovation. But Sun (and Oracle) failed to provide good "soil" so it could grow.
Now Oracle tries to use Swing's depleted soil to grow the JavaFX 2.
IMO JavaFX Script is the right tool for the job (building the UI) and any multi-purpose language (Java, Groovy, Scala, Jython etc) won't be.

Posted by IvanoBulo on February 17, 2011 at 01:03 PM CET #

Screencast or it didnt happen.

Posted by Sakuraba on February 17, 2011 at 01:58 PM CET #

Will there be a NetBeans designer for creating stages?

Will the WebBrowser control be able to display pages which include JavaScript?

Will jfxrt.jar be included as part of Java 7?

Posted by Sam Lalani on February 20, 2011 at 10:35 PM CET #


I only can say: it looks good :-)

Some of the questions are answered here already:

And it is official. I'm not an Oracle employee - just a freelancer who likes Java(FX),



Posted by on February 21, 2011 at 05:08 PM CET #

Thanks for the sample!

I have failed to find and document on how to integrate JavaFX with EE 6 enterprise features (CDI/EJB injection + remoting, Bean Validation, exception propagation, CDI events etc), do you have any insight?

I'm looking for an alternative view layer to JSF 2 and looking for information on what can be re-used and what not.

Thanks in advance,

Posted by Nicklas Karlsson on March 01, 2011 at 10:46 AM CET #

where clould i


Posted by ravenocean on April 15, 2011 at 02:25 PM CEST #

Thank you for the example!

javafx 2.0 is more desirable, but how can I get it. I'm searching for a while to get the package, but until now i found nothing. Isn't released?!

I hope you help me.

thank you for every thing

Posted by Muhammad A. Maqtary on April 21, 2011 at 11:49 PM CEST #

Hi Adam,

Is JavaFX 2 completely independent from AWT APIs?

You know some Swing components used to extend java.awt.Component and some of the listeners used in Swing were from the AWT package...

Posted by Behrang on May 15, 2011 at 11:16 AM CEST #

Hai Adam,

Can you give me an example that implementing javafx to build video confrence application?


Thanx before,
Hantze Sudarma

Posted by Hantze on August 06, 2011 at 09:35 PM CEST #

yes a reference example with sample project structure will be very handy. pls. see if you find some time to upload the same.

Posted by Java Experience on December 19, 2012 at 06:03 PM CET #

Post a Comment:
  • HTML Syntax: NOT allowed
...the last 150 posts
...the last 10 comments