I've been a zone leader with DZone since 2008, and I'm crazy about community. Every day I get to work with the best that JavaScript, HTML5, Android and iOS has to offer, creating apps that truly make at difference, as principal front-end architect at Avego. James is a DZone Zone Leader and has posted 639 posts at DZone. You can read more from them at their website. View Full User Profile

What Does JavaFX Mean For You?

  • submit to reddit

There's a lot of hype, talk and tutorials going on around JavaFX. What I'd like to do in this article is to take a step back and discuss what JavaFX means for you (and me), the ordinary Java developer. With technologies like JavaFX, it's easy to get caught up in the details, but more difficult to work out if it's something that you really need to consider.

A Brief History

JavaFX is a rich client platform that allows you to create applications that will work across multiple devices. Currently, these devices include desktop and mobile targets. One of the key advantages to JavaFX is that the code you write for one of these devices will work on any other device. As JavaFX is integrated with the Java runtime, it will run on any desktop with Java installed, and will run on any phone that provides JavaME.

JavaFX was first announced by Sun at JavaONE 2007. Version 1.0 was released in December 2008, targetted at the desktop platform while 1.1 was released recently for mobile devices.  To put it simply, JavaFX is Sun's competition to the two main RIA implementations available - Microsoft's SilverLight and Adobe's Flex/AIR.

Looking at the situation in greater detail, JavaFX's main strength comes for how it can interact with Java code, and Swing components. Some are sceptical of Sun's investment into JavaFX - thinking it would be better to invest more on Swing - but it certainly opens some more doors for Java developers. Already JavaFX has seen some very high download numbers - before version  1.1 was released the runtime was heading for over 80 million downloads.

What Can JavaFX Do That Swing Can't?

One of the really nice things in JavaFX is the ability to drag a JavaFX application from inside your web browser to the desktop. This in turn makes it easier to create applications like WidgetFX, which provides desktop widgets.  Rich video content is made possible through the On2 video codecs which are supplied with JavaFX. It's worth noting that these same codecs can work in your Swing applications too.

JavaFX applications are written in JavaFX Script. The script takes advantage of a general scene graph model, that allows effects, transforms and animations in your UI. Using JavaFX Script you can put user interfaces together quickly, as the language is written specifically for user interface creation. The resulting applications have a richer, smoother feel than standard Swing applications.

A Place For JavaFX In The Technology Stack

The term Rich Internet Application can be defined as an web application that takes on the characteristics of a desktop application. When most people think of an RIA, they will think of Flash. Maybe it's just that we've blocked it all out from memory, but Java Applets provided us with the first real RIA. 10 years on, learning from the past, Sun have given a new way for Java developers onto the web.

So, where does writing applications in JavaFX make sense?  The key use case for me, is for those who are starting an application from scratch. If it needs to interact with other Java components and libraries, JavaFX is a good choice for your UI layer. If you want to write an application to work on the desktop and on mobile devices, with minimal deployment headaches, this is the technology you need. The single-sourcing aspect of JavaFX is the main advantage.

Things get muddier when you are considering JavaFX for your current applications. As it stands now, there is no official way to get JavaFX embedded into your Swing (or SWT) application. There is a workaround available, I'm just not sure if I'd use that in applications that go out for production. From talking to the JavaFX team, it seems that this issue will be addressed in future releases. With a good architecture, and clean seperation of your UI layer, it should be possible to move your UI code to JavaFX.

For those writing for mobile devices, JavaFX gives much richer graphics and UI's than JavaME does. It's easier to code for mobile with JavaFX too, and easier to test, due to the same programming model being used for desktop and mobile.

In summary, if you're starting fresh, and want to have a user interface that is 'flashier' than what you can do right now with Swing, JavaFX is a good choice.

Where Can You Get It?

There are three different components to the JavaFX download. The SDK includes the JavaFX compiler, runtime tools and the various libraries for video, graphics and web services that are needed to create your applications for the mobile or desktop platforms. 

There is also a Netbeans plugin available for JavaFX. The download site provides a link to download the complete Netbeans IDE (6.5) for JavaFX. This will help you create JavaFX applications even faster, and provides a mobile emulator so that you can preview you application for a mobile device.

Finally, the JavaFX 1.1 Production Suite is a suite of tools and plugins that enable designers to export graphical assets to JavaFX applications. This is probably of least interest to Java developers, and is aimed more at graphical designers.

For those who prefer to work with Eclipse, there is also a plugin available, allowing you to add a JavaFX nature to your project.

Writing JavaFX Applications

In terms of getting start with JavaFX scripting, the best place to go is to Netbeans and take a look at the sample projects there. A gallery of samples are also listed on the JavaFX.com site.  Stephen Chin's WidgetFX project - a desktop widget platform written in JavaFX - is also a great example of what can be done with JavaFX. Stephen is writing a book with Jim Weaver at the moment, Pro JavaFX Platform which is in early access at the moment.

It's still early days for JavaFX. If you're looking for an alternative to Flash, and you are already familiar with Java, it's worth taking a look at. In the upcoming releases, I'm sure we'll start to see strong reasons to go with JavaFX as your UI technology for Java applications.

This is all just my own opinion however. I'm interested to hear what you think the the key points are that make JavaFX a good technology choice?


Logically Genius replied on Mon, 2009/03/09 - 3:26am

Whats the Bloat size ?

Guido Amabili replied on Mon, 2009/03/09 - 3:48am

The key points for using javafx, as far as I did understand it:

  1. Use of existing java libraries (swing,swingx, commons.io, ftp,groovy, osgi, etc...)
  2. Customize the ui of the application much more easily then with swing (and I love swing)
  3. Do some animations
  4. And last but not least the same code could run on mobile devices...

I have now 1 week break to learn JavaFX and I will use it to learn a small desktop application with a few use cases (login, submit/download files  via ftp, reporting, json http communication) and I will use JavaFX.

In our team, there are some projects going on with Flex/Air but people are rapidly finding out the limits of such solutions.



James Sugrue replied on Mon, 2009/03/09 - 4:06am in response to: Guido Amabili

Sounds interesting Guido. It would be great to find out more about the limitations that the Flex/Air implementations are hitting. And if JavaFX gets around those issues.

Guido Amabili replied on Mon, 2009/03/09 - 6:42am in response to: James Sugrue


As much as I can tell,(they were discovering flex and trying to replace an existing webstart application), they had some problems with threading and filesystem access.(this was a couple of month ago)

I think one of the strength of the javafx platform vs Flex/Air, you can write "desktop" applications and not only server front-ends.

And after my first lessons in JavaFX, I think it's great that you can mix your "core" classes written in Java with your GUI written in JavaFX.(thus enabling possibly better application design)




Osvaldo Doederlein replied on Mon, 2009/03/09 - 7:43am

I never hacked any Flash/Flex, but as the editor of a Java magazine I started to accept a few articles on Flex, on the basis that some people are using that as front-end for Java enterprise apps. So I've been learning some high-level Flex/AIR stuff in order to review the articles.

It seems to me that Flex is good where Java (in general) is weak, but not much else. The Flash runtime has the seamless installation, near-zero startup time [but not with Flex!], and low footprint that Java is still struggling to achieve even after 6u10's many enhancements. And it's good all media coolness (great video, audio and animation) that Java is only offering with JavaFX (which is still very new, and less mature). Not to mention design tools, a space where Adobe rules.

And... that's it. Flex's APIs (except for media, UI and in part networking) are more comparable to Java ME's (or perhaps Android's) than to Java SE's. Its library deployment strategy seems stupid to me - libs are packaged into each application, so they don't need an extra, big runtime (sort of each applet using Swing having to be bundled with swing.jar). The resul, any HelloWorld-class Flex app (like those from the SDK's samples/explorer) produces a 180Kb+ .swf file (that's compressed size), when a comparable Swing or JavaFX applet would be perhaps 2-5Kb. And Swing's UI components are much richer. Right now, Flex's entire library is not very big, but it can only grow as they keep competing on features with Java SE and .NET.

Adobe has zero server-side story, so they have to play nicely with Java or .NET back-ends, with solutions like BlazeDS. But I suspect that as you move into really complex apps, whatever productivity advantage that Flex offers can be lost to the integration effort, e.g. because you have to recode all your domain objects in AS3, marshall stuff to/from Java etc., instead of simply reusing all POJOs and other client-side objects of a JavaEE app. And don't get me started with web services / SOA... Flex goes the old way of SOAP and RPC, while the world moves to REST and document-centric services. But hey, it's "rapid development" technology, not something for people who create nontrivial apps with modern engineering.

Jeroen Wenting replied on Mon, 2009/03/09 - 7:49am

JavaFX means nothing to me, whatsoever. I hardly ever create Swing applications, and never applets. I also loath Flash applets/applications.

James Sugrue replied on Mon, 2009/03/09 - 8:11am in response to: Jeroen Wenting

That's interesting Jeroen. Just wondering - when it comes to UI technologies, which do you use?

James Sugrue replied on Mon, 2009/03/09 - 8:20am

Another nice example of JavaFX in action : http://jfxstudio.wordpress.com/2009/03/03/the-graphic-database-front-end/

Michael Bien replied on Mon, 2009/03/09 - 10:53am

>What Can JavaFX Do That Swing Can't?

>One of the really nice things in JavaFX is the ability to drag a JavaFX application this is ...

 this is a standart 6u10 feature and goes hand in hand with the out of process functionality - its not JavaFX exclusive. You basically only have to overwrite one or two methods of JApplet and set a flag in the jnlp and you have a draggable applet.


James Sugrue replied on Mon, 2009/03/09 - 10:57am in response to: Michael Bien

Right Michael - my mistake. I got blinded by the JavaFX lights there :-) Thanks for the correction

Mike P(Okidoky) replied on Mon, 2009/03/09 - 12:22pm

Great comments.

Is anyone concerned at all about performance for anything more than a trivial application?

Also, do larger applications hold up over time, meaning, if you write something and leave it for a few months, and go back to it, how easy is it to pick up where you left off? How much mental note keeping does writing JavaFX require? These mental notes disappear when you leave things for a while. Of course, commenting and documenting always helps, but we all know what type of documenting disciplines exist in companies - which is more often than not, none.

Or perhaps JavaFX allows you to define details in a more hierarchical manner, which actually makes it more self documenting. (Using Allman/Ansi style indentation instead of K&R would certainly help btw).

Lastly, how does it hold up in development teams? Are changes that people generally make to other people's code more automatically in line with the mindset of the designed code? I've seen many times, where people make changes to other people's code without understanding very well how things are put together. Rogue hacky code bits start to appear in traditional Java source that are out of place, that often needs refactoring later. Perhaps in JavaFX we'd see less of that...?

Ted Young replied on Mon, 2009/03/09 - 2:46pm

Based on the JavaFX applications I've seen, the UIs are nowhere near as nice as those I've seen rendered in Flex. Now, that may be the newness of JavaFX, but the out-of-the-box text rendering appears to be pretty poor in comparison to Swing apps. Text should be anti-aliased properly by default, but doesn't appear so.

Alas, in the apps I've seen (and this isn't just JavaFX), the usability is poor. No framework will do away with lots of thinking around usability, but it seems we could be doing a lot better -- see Apple's frameworks, for example.




Developer Dude replied on Mon, 2009/03/09 - 2:53pm

So far JavaFX means little to me except that I am worried about all the talk of it being the future of UI development in Java instead of Swing. The apparent abandonment (or the rumors thereof) of Swing development by Sun in favor of JFX doesn't give me the warm and fuzzies. I don't write 'flashy' UIs - I write productive business apps with efficient workflows to help automate business processes, not games, not interfaces with animation, or video, or audio. I have no need or desire for 'flash'/etc. Moreover, JavaFX doesn't get around the problem of the user having to either install a JVM or download it with you app, and/or enabling it if they do have it. I know, I know, it is supposed to make it easier - but the real problem is one of user perception and I don't see JFX having any real impact there. So, if I want to write a Java app that works (as an app) in a browser, it will most likely be in GWT. If I want a Java app to have a desktop UI, then I will write it in Swing.

Sergey Surikov replied on Tue, 2009/03/10 - 2:39am

Look to statistic


How you see, most of developers need tools for business.
No toys, no cool, no fun just boring office or enterprise applications.

Dimitris Menounos replied on Tue, 2009/03/10 - 3:52am in response to: Logically Genius

Whats the Bloat size ?


Jeroen Wenting replied on Tue, 2009/03/10 - 4:23am in response to: James Sugrue

"when it comes to UI technologies, which do you use"
JSF, or something else that generates html.
Or Swing, the rare times I might want a thick client written in Java (rather than Delphi or C#).
But most of what I do either has no graphical interface at all (web services, EJBs, etc.) or needs no more than a commandline interface.

Sergey Surikov replied on Tue, 2009/03/10 - 4:37am

But most of what I do either has no graphical interface at all


so you don't need JavaFX

Most of what i do is GUI for DB. I need rich grid and other components in JavaFX. I don't need new videoplayer


George Jiang replied on Tue, 2009/03/10 - 6:34am in response to: Mike P(Okidoky)

It appears that with JavaFX, only the UI part is developed in JavaFX script. The rest can be developed in Java.

Also, it is a good thing the Java Platform is more and more multilingual, as proved an interesting approach on .NET

Markus Kohler replied on Tue, 2009/03/10 - 8:06am in response to: Mike P(Okidoky)

Regarding performance you may want to check this post about JavaFX's memory usage

Ayodeji Aladejebi replied on Tue, 2009/03/10 - 11:46am

To me, JavaFX is supposed to be something where you can fire up Netbeans, open a canvas, drag a video source to it, drag in controls of play , stop and volume then boom export to web, mobile and desktop with No code in between all dat :) ok dats fantasy

Mike P(Okidoky) replied on Tue, 2009/03/10 - 12:44pm in response to: Markus Kohler

Markus, the link doesn't work.

Osvaldo Doederlein replied on Tue, 2009/03/10 - 2:03pm

@Dabar: We're not very far from this goal; Sun will deliver a visual JavaFX designer for NetBeans 6.7 in june (hopefully we may have some betas before J1?). Right now a visual designer is not of much help because JavaFX 1.1 is still missing its native componente package; but this is promised for JavaFX 1.5 which is also coming up in june.

I guess it would be cool to compose simple media-centric apps 100% visually, I don't know if the first release of the designer (and component package) will contemplate this scenario, or just common controls like Swing's (buttons, grids etc.). I'm crossing my fingers so JavaFX 1.5 will have a decent, modern component package, including facilites that Swing still misses as standard, like easy and powerful validation or a date picker... well, at least data binding is guaranteed that won't be missing. ;-) If Sun gets this basic stuff right, you'll be able to add a MediaPlayer component (if that's missing) with a page of code.

Moving beyond that, how about visual development of front-ends to back-end data source (EJBs, XML, AJAX, SQL)? This would need data-aware components, and JavaFX's powerful binding mechanism probably makes easy to write such components. But now you enter in the domain of functionality that's not extremely important (even developers of front-end apps often don't like thedata-aware component paradigm), and not easy to implement - if you consider complications like a generic data access layer that allows the same components to talk to a variety of data sources, and the multiple back-ends of that layer to support all popular data sources. And it's probably a good idea to let the brand-new native component package mature a lite bit, before adding another layer of standard APIs on top of it. So this is perhaps a good hint at the functionality of JavaFX 2.0...

Thierry Milard replied on Tue, 2009/03/10 - 8:47pm

I am typicall a Swing mature developper. I love beautifull things. I love guis.

I try to do Web services so I really need a Flash or javaFx toolkit thing...

I am/was excited about javaFx. I tested the langage and I found it good : 'A simpler java'.


But I just can not go yet to it for two reasons.

1) The java jre problems :

Truelly the jre since 1.6.0_12 is getting good. But still .... it still starts too slowly. those 5 8 seconds for the moments you click on the web link to the moment the jre is ready to'start' running your program is just to slow.

The future of javaFx is somehow (still) linked to this big issue. If only sun had a way to QUICKLY solve this. I heard that for java 1.7 it could be different.... Man ! But it's in 2010. We will all be dead by then. No ?

2) Mixing javaFx and Swing should be easy and native.

I have a mature Swing application and I would like on a few screen to put some nice javaFx transitions and animations. The problem is that it is not simple to do this if I understood some previous post. It sounds difficult to integrate a javaFx small animation in a swing panel. This is bad. Really. From MPOV this issue should be priority number one for javaFx/Swing  team. Just think of the thousands of existing Swing application that need rewamping and visual improvements ... otherwise they will sooner or later try another platform.

Above all I really think it is much much easier to convice Swing people tojavaFx a bit a ther application than to convice web developpers. At least for now.


Alexander Shirkov replied on Wed, 2009/03/11 - 3:58am

1) I need advanced datagrid with ability to place pictures, checkboxes, buttons, multiple different components into single column. Flex gives me such possibility, JavaFX still not.

2)JavaFX needs cool demos. Look at Adobe's - they're pretty good. And look at JavaFX - just a shadow of really pretty and nice app.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.