SQL Zone is brought to you in partnership with:

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

How Can Oracle Make JavaFX More Popular?

  • submit to reddit
In JavaFX is a Train Wreck, Kirill Grouchnikov asks why he has yet to see a good looking JavaFX application. I always expected JavaFX to be more popular than it turned out to be, especially when the Java Store was launched, but maybe there's no place in the software development world for JavaFX anymore. On the mobile, Android seems to be the language of choice for Java developers, which is unsurprising given the huge potential for the platform. On the browser, developers are spoilt for rich frameworks. If it focussed on the desktop only, perhaps JavaFX would be a compelling option. Or maybe we're about to see a wave of new JavaFX apps following the release of JavaFX Composer with NetBeans 6.9.

Microsoft know they're up against it when trying to sell their Windows Phone 7  with competitors like Apple, Google and RIM. Their solution? Give developers handsets, tools and cash for developin apps for their new platform. It might just work. Should Oracle look at this model to improve the adoption of JavaFX?
Three years later, is JavaFX a relatively unused technology? And if so, what can be done to change the outlook for JavaFX?


Thomas Buhr replied on Thu, 2010/07/15 - 1:31pm

Well its finally come to this shoot out and thats fine by me. For my particular application I found that the whole scenegraph retained node approach would not work, rather the old fashioned immediate Java2D approach was best. There were reasons for this including: visual nodes duplicating what my model already had, memory and performance expense.

What I'd now like to use JavaFX for is for cute widgets, just stuff that decorates the UI. However even that is a challenge because the Java to JavaFX bridge has never been properly provided. I'm just happy now that I have good APIs to work with in Java7 including Java2D with XRender improvements, shaped and transparent windows and the fantastic JLayer.

I just got news about the new open source Sage 1.0 update from Sparseware. It is quite amazing that one main developer can develop Sage and an IDE to go with it, complete with browser and HTML5 support, yet JavaFX has a bigger team and has yet to do the type of demos that the Sage site or download include.

The things that suck worst about JavaFX are that there is no roadmap (no one steps up and tells us where we are going and can expect to do with that) and the JavaFX Authoring Tool never arrives. I agree open sourcing JavaFX is the only way forward given the lack of sunshine we've been getting from Oracle so far.

Checkout Sage here: http://www.sparseware.com/sage/demos/index.html


Geertjan Wielenga replied on Thu, 2010/07/15 - 2:24pm in response to: Mikael Grev

Animations... maybe. That's all, I think. Would be nice for welcome screens, and similar eye candy places, in existing Swing applications. Other than that, for large mission-critical Java desktop Swing business applications (e.g., defence, aerospace, banking), I don't see the significance of JavaFX for the desktop, at all. No one is going to port their existing massive Swing applications to JavaFX and, until JavaFX is offered as a standard course at universities, i.e., while JavaFX is a non standard UI toolkit, organizations will not adopt it for their mission critical applications. SWT has the same problem: it's non standard. Organizations like standards and for that reason, even in the absence of any other reason, they'll prefer Swing (for the same reason as choosing OSGi) on the Java desktop.

Sergey Surikov replied on Thu, 2010/07/15 - 3:34pm in response to: Guido Amabili

How many guys that want to kill JavaFX.... but how many did try ?

Sun promised technology for easy GUI building. Many people beleived in it and started investment in JavaFX projects. Sun hasn't fulfilled promises so that developers lost money. This is why so many angry people here.


Max Katz replied on Thu, 2010/07/15 - 3:41pm in response to: Geertjan Wielenga

Standards are important but not that much. Struts is not a standard and companies use it. GWT is not a standard and companies use it. jQuery is not a standard and companies use it..I can list many more.

The main reason JavaFX has failed so far is: deployment, deployment, deployment.


Geertjan Wielenga replied on Thu, 2010/07/15 - 3:53pm in response to: Max Katz

But what standard-based alternative is there for GWT and jQuery? If there was a standard for AJAX, that's what organizations would use. And Struts is only used because it's been around so long that it's pretty much a defacto standard, together with JSF. General acceptance of JavaFX as a way to solve some specific problem (though I'm not sure what that problem is, though that problem may still be identified, i.e., people often use a solution for something different to what it was intended) is, in my humble opinion, the main problem it's facing. That's why I'm looking forward to it being easier/standardized to integrate it into existing Java desktop applications, because then it will have a chance to find its niche. Trying to justify its existence without reference to anything else (i.e., as some kind of Swing 2.0) is problematic.

Max Katz replied on Thu, 2010/07/15 - 4:43pm in response to: Geertjan Wielenga

Well.. in theory JavaFX could be used anywhere Flash/Flex is used today.

Behrang Saeedzadeh replied on Fri, 2010/07/16 - 1:33am

Decouple JavaFX from JavaFX script. I really like to play more with JavaFX but I can't bear with the ugly syntax of JavaFX Script. We should be able to write JavaFX apps in Java, JavaScript, Groovy, JRuby, etc. Seriously, why is JavaFX Script so ugly and lacking?

Otengi Miloskov replied on Fri, 2010/07/16 - 1:47am in response to: Behrang Saeedzadeh

Thats a good point there, We should be able to use the JavaFX libs with Java or Groovy or Javascript and dump the stupid JavaFX script is ugly as hell.

Shai Almog replied on Fri, 2010/07/16 - 3:26am

I noticed the lack of mobile discussion except for a couple of Android related posts. I'm curious how the mobile crowd sees Java FX but I assume there aren't many mobile developers in the JavaLobby due to relatively low amounts of mobile content.

For that means I published an almost identical poll in my blog which attracts a good segment of the mobile Java developmnet community here: http://lwuit.blogspot.com/2010/07/how-can-oracle-make-javafx-more-popular.html

I'm curious if our results will be different due to the population segments.

Silvio Bierman replied on Fri, 2010/07/16 - 5:23am in response to: Behrang Saeedzadeh

Dead on. JavaFX is useless for anything other than toy projects because it does not decouple the library and the language. Every Java developer would jump on a well designed, sexy looking and cross-platform UI class library. And Scala, Groovy etc. developers would gladly follow. Give us the library (and extend it) leaving us the option to not use the hardly-language. Otherwise, don't bother me with this any more.

Sergey Surikov replied on Fri, 2010/07/16 - 5:55am in response to: Shai Almog

JavaFX doesn't support mobile development. All that promises are fake. You can run JavaFX mobile application on emulator only.

Alan O'Leary replied on Fri, 2010/07/16 - 9:18am in response to: Geertjan Wielenga

Geertjan Wielenga replied on Thu, 2010/07/15 - 10:47am

I think JavaFX will become more relevant once it is possible to use it in substantial desktop applications, i.e., existing modular Swing applications. Without that integration, though, it's a piece of a puzzle without a puzzle to put it into.

Have to completly agree with this statement - the biggest asset to JavaFX is all the Swing developers - but these are being ignored. The Swing integration is becoming less supported if changes in 1.3 are a hint of things to come..

We have decided to stick with Swing for now - at least some of the updates to the JVM around the client vm and WebStart will be of benefit.

Would love to gradually introduce JavaFX to existing Swing apps but this is not technically possible (officially) and also the licensing is an issue...

If we are actually forced to rewrite our Swing apps we will just go with a HTML5 option.

Greg Brown replied on Fri, 2010/07/16 - 10:38am in response to: Silvio Bierman

Hi Silvio,

Take a look at Apache Pivot (http://pivot.apache.org/). It aims to provide exactly what you describe - a well-designed, cross-platform UI library that works with any JVM-compatible language.


Greg Brown replied on Fri, 2010/07/16 - 10:42am in response to: Alan O'Leary

Hi Alan,

You may also want to take a look at Apache Pivot (http://pivot.apache.org/). Pivot 2.0 (currently in development) allows you to easily embed Pivot components within a Swing application. This may help lower the barrier to migrating away from Swing, if you decide to go that route.


Alan O'Leary replied on Fri, 2010/07/16 - 11:59am in response to: Greg Brown

Thanks for that - didn't realise you could do that - I had seen I could not embed Swing Panels in Pivot so didn't dig further .. but If i could embed pivot in Swing might be interesting....

Greg Brown replied on Fri, 2010/07/16 - 12:38pm in response to: Alan O'Leary

Here's an example. It shows a JDesktopPane containing two internal frames - one that contains Swing components and another containing Pivot components:


The source code is here, in case you are interested:


Gregory Smith replied on Fri, 2010/07/16 - 1:22pm

Replace JavaFX with Apache Pivot. Pivot is what JavaFX should have been. JavaFX effects could be added to Pivot - the rest of JavaFX should be thrown out.

Chad Salamon replied on Fri, 2010/07/16 - 1:41pm

I've started using JavaFX in my personal applications, and I've simply fallen in love with it. However I would be hard pressed to seriously consider recommending JavaFX for any work related project for several reasons. The tools still need work - the visual designer in NetBeans is worthless. On top of that you have the big problem of retraining developers. I went through several frustrating experiences before I figured out some of the gotchas in JavaFX (and I highly recommend Amy Fowler's presentation on layout managers). That didn't cost me anything but some free time I devote to programming anyway, but in a company that learning curve can be costly. To be justified JavaFX has to be able to make up for it somehow. But where does it make up for it? On the web you have other options which developers are likely to be more familiar with. On mobile phones JavaFX has virtually no market share. That leaves the desktop.

On the desktop JavaFX does have some strong suits. I've always been annoyed with Java UI development, even while I enjoyed using it on the server. There are several reasons for that, including the ugly appearance of the UI in the past. But I think the main reason is that Java is a very cumbersome language for UI development. Function pointers are a basic concept for any event driven UI framework, but Java lacks them, and anonymous inner classes are a hack workaround. Object initialization is incredibly cumbersome when setting a large number of properties (in some languages this is handled with separate form files with a better syntax). These problems aren't an issue for server development, but for client UI development they require you to create cumbersome boilerplate code that is harder to read.

JavaFX solved these problems by making function references and a nice object initialization syntax a part of the base UI. It would have been hard to shoehorn these types of features in to Java, so I understand why they went with a new language. On top of that JavaFX has features that really save some time in UI development. Most notible is bind with inverse, which allows you to bind UI components to domain objects without a bunch of code to regularly copy stuff back and forth. And then of course there is far better media support. That's actually the main reason I went to JavaFX - I was considering building in Java and I needed video support. I was trying to figure out how to do it and a website directed me to JavaFX. I know there are complaints about JavaFX's capabilities (lack of controls) but you can still call back to Swing (for now?). It may be cumbersome but to me it seems less annoying then using Swing for all of my coding.

The RIA, mobile, web and TV capabilities seem more like a bonus for Swing developers than a legitimate reason to consider JavaFX. If you already have a reason to develop UIs in Java for the desktop then why not do it in a framework that may open up the possibility for other platforms in the future? But if you want to build web applications to start with, then you will no doubt be better served by using an alternative technology.

I think that Sun/Oracle's main problem is that they are seeing JavaFX in terms of its potential, not its current capabilities. In my opinion JavaFX at its core is simply not an RIA platform at all. It is a rich desktop application platform with internet capabilities and the ability to segway into an RIA platform at some time in the future. That doesn't make for a very good acronym though.

If you already have a reason to consider Java for a desktop application (you want it to be cross platform and you need some of the many capabilities handled by existing Java libraries and frameworks), then I can strongly recommend at least keeping an eye on JavaFX. However, I can't see enough of a reason to consider it in web or mobile environments compared to the alternatives.

Erik Martino replied on Mon, 2010/07/19 - 12:19am

They should sort out the license under which you are allowed to distribute the JavaFX runtime. It is not possible to ship a product that doesn't use Java Webstart. For most products that is not an option

Andrew Fink replied on Mon, 2010/07/19 - 12:21am

1. better Java and JavaFx integration (now you can easy call java from javafx, but calling javafx from java (from spring, for example) is hard.


2. better Swing and JavaFx integration - same problem as #1. 99% users want to insert javafx in their existing Swing application


3. better business components 


4. open source javafx


Tom Hite replied on Thu, 2010/07/22 - 1:55pm

Stop development on JavaFX? How would that benefit anyone? I would put MORE resources into it and tie it closely to Java 7. And Groovy. And get it on Android and the new Nokia, Windows Phone 7 and Qualcomm phones. Also Apple will have to drop its ban on VMs once Android starts pulling away from iPhones in numbers. JavaFX should run on the new Linux based tablets coming out.

Donald Mcronald replied on Thu, 2010/07/22 - 2:36pm

I almost didn't comment on this. I think JavaFX is a good technology and has a lot of potential, so I hate to write anything that may discourage anyone from trying it. However...

I agree with a lot of the complaints here. I don't think open sourcing JavaFX is a good solution though. In my opinion the last thing it needs is for someone to fork it and fracture the developer base. I wouldn't complain about a commitment to open sourcing it if they ever decide to kill it though.

My complaints (in order):


The current licensing is, by far, the biggest drawback to JavaFX. It's unworkable. We need to be allowed to redistribute the runtime. There's no point in rehashing why though. There's already plenty of feedback out there. It's just that Sun (Oracle) doesn't seem to be listening. Speaking of which...

Community Interaction

I've seen some of the devs posting on the forums here and there and they deserve some praise for that. However, in terms of project management, it feels like I'd get better answers from a magic 8-ball than from Sun. There is NO community feedback. I have no idea what their vision is for JavaFX. I have no idea when the next release is going to happen. I have no idea when it's going to be on mobile devices or tablets. I'm sure you get the point.

There are things that have been ignored for YEARS; licensing is one of those things. People have been asking for better licensing terms since version 1.0. Sun's reaction? They have an undated, single line comment on the uservoice site saying they plan to review it. That's pitiful. Give us some real feedback.

I've also seen instances where I have no idea why some things have been ignored. There's an issue in JIRA asking for Maven support. Someone did an implementation and was willing to contribute it. All Sun needed to do was say thank you and host it somewhere. It's months later and nothing has happened with it. Why? All Sun needs to do to add Maven support to JavaFX is pick one of the several existing implementations, endorse it and let them redistribute the runtime. I can't describe the rage I feel every time I check that JIRA issue. Seriously, why?


This can be summarized by noting they used Java Web Start as a solution. The concept of JWS is great. The implementation sucks. It provides a terrible user experience. I would be embarrassed to sell an application using a deployment system like that. Considering it's been 15+ years for Java and JWS is the best thing Sun could come up with for desktop deployment, is it any wonder I'm not content to trust them to come up with a deployment solution?

Let us redistribute the runtime and some of the Java based deployment solutions will spill over to JavaFX. If there were a decent Maven repository for the JavaFX libraries I could extend the build configuration I use for Install4J in an afternoon. My build server could spit out an Install4J installer for my JavaFX applications just like it does for my Java applications.

Then there's the applet. It's a house of cards teetering on the brink of collapse. First, it uses JWS which already needs some polish. Then they add in some Javascript on a third party site (Sun's) and top it off with, from the end-users perspective, the auto-magical download and installation of the JavaFX runtime. Through all of that there's no feedback to the end-user about what's going on.

Deploying a Flex application starts and finishes with dropping a .swf file on the web server. JavaFX deployment starts with a pot of coffee.

Documentation & Samples

I don't care too much about documentation. I can figure out most of what I need to do on my own. However, it has an impact on JavaFX adoption which has an impact on the platform itself, so it still concerns me. We need more documentation, but not at the expense of actual development on the platform.

The API has some rough spots though. I've seen a few parts of the API that made me question the competence of the person that wrote the code. I'd like to know who's writing concurrency related libraries without realizing it's asynchronously, not asynchrously.

As for code & application samples, I don't think I've ever seen a JavaFX application that struck me as being amazing, but I know it's possible. There are a lot of samples out there, but most of them look unfinished. I understand it takes a lot of time to really polish samples and don't expect it all the time, but a few very good looking demos on the JavaFX home page would go a long way. Speaking of which...

The JavaFX Site / Branding

The word applet should never have appeared on the same page as JavaFX. Most people think of applets as a crappy failed technology from the 90s. JavaFX is so much more than applets. Too bad the main JavaFX site re-enforces the former viewpoint more than the latter.

I also see a lot of people that don't know the difference between a plugin based platform and a web based platform. JavaFX and HTML5 aren't even close to the same type of platform. Maybe that's why so many people develop productivity applications using web based platforms rather than plugin based platforms.

Don't let people compare HTML5 to JavaFX. JavaFX can do everything that HTML5 can, plus a whole lot more. Emphasize that point. Web based platforms are children's toys when compared to plugin based platforms. Tell people that. Don't even let them compare the two. Laugh at them if they try. Literally.


I don't want to use Netbeans. Why can't we have a standalone UI designer? I like the workflow I was able to create using JFormDesigner in stand-alone mode and it didn't lock me into any one specific IDE.

JavaFX has the potential to be a massive success, but Sun (Oracle) needs to do one of two things to make that happen:

1) Invest in it more.

2) Get out of the way and let the community invest in it more.

If they don't want to loosen the licensing and let the community in, they need to pick up the slack on things like Maven support, tooling, deployment, etc.. The current situation is analogous to someone winning the lotto, refusing to cash the ticket and refusing to give the winning ticket to someone that would cash it.

In my opinion the vast majority of JavaFXs problems are non-technical. JavaFX needs a leader with a vision. We need someone that can communicate that vision to the community and push the platform in that direction. Right now, I have no idea who's in charge or what the plan is. For all I know I could walk into Target tomorrow and find a JavaFX branded coffee pot.

I could rant for hours, but I have to do some actual work today. Just once I'd like to see Sun (Oracle) respond to some of the criticism in this whole thread (everyone's criticisms). Sometimes I even embellish my critiques hoping they'll call me out on some of the more questionable things, but... nothing. Really, I'm starting to wonder if they're even connected to the internet over there.

Donald McRonald

Sergey Surikov replied on Thu, 2010/07/22 - 10:58pm in response to: Donald Mcronald

In my opinion the vast majority of JavaFXs problems are non-technical. JavaFX needs a leader with a vision.


Carla Brian replied on Sun, 2012/07/22 - 6:12pm

JavaFX provides a productive development environment for web developers, mashup authors, and Java developers to quickly and easily build the next generation of rich internet application. - Mercy Ministries

Comment viewing options

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