I don’t know any other technology that has ever gotten as much of a beating as JavaFX did last week (here, here, and here). JavaFX has become a technology that developers love to hate. It’s like a pinata for developers.
JavaFX was first announced at JavaOne 2007 (that’s 3 years ago). Many predicted its death even before version 1.0 was released in December 2008, and many continue to call for its demise.
Last week also turned out to be the week where I presented Enterprise JavaFX at the Silicon Valley JavaFX JUG, and also the week that Steven Chin created a petition to open source JavaFX.
Don’t get me wrong, JavaFX is very far from perfect. It has it’s problems and challenges (listed below) and its future is hanging on life support right now, but let’s start with the good.
The good stuff
JavaFX Script is a very powerful language. In fact, it’s a DSL (Domain Specific Language) for creating rich user interfaces where the resulting application runs inside the Java virtual machine on the client. JavaFX Script might appear foreign at first (as probably any new programming language would) but after using it for a while you start realizing it’s power and ease of use. The JavaFX binding feature simplifies UI development even further by tracking model changes automatically. I have been working with JSF (JavaServer Faces) since its inception and I can tell you that using JavaFX Script to build the UI is probably simpler than using JSF. As JavaFX applications run inside the Java virtual machine which is very powerful, this allows us to build rather rich and sophisticated client applications.
The ugly stuff
As the mantra in real estate is: location, location, location. The mantra in JavaFX is: deployment, deployment, deployment. Unfortunately, this is where JavaFX has failed miserably. The original Java applets failed miserably in deployment and JavaFX (which was supposed to be the next applet technology or applets 2.0) has inherited the failed deployment with it. In other words, nothing has really changed since 1995. I don’t understand why Oracle (previously Sun) has allowed this to happen. I know that Oracle has some very smart people who could have fixed it a long time ago.
This is what happens most of the time. You click on a link to launch a JavaFX application as an applet inside the browser. Let’s assume that you already have the Java plug-in installed. The browser freezes for about 5 seconds. After the 5 or so seconds, you will see the a Java logo inside a dotted circle. The dotted circle is moving around as if to show the loading of the applet. The sad thing is that it’s just an animated GIF and doesn’t show the actual loading progress. Why is it so difficult to show some sort of progress status of the actual loading?
This is where it gets even more interesting. If you are lucky, you will see a rather scary security dialog (you have to click “yes”) and after that the application will appear. If you are not lucky, you will continue seeing the moving image (with the Java logo inside) forever or until you close the browser window. Nothing else will happen. No error message. No reason why the applet was loaded. Nothing. If you want to know why the applet failed to load, you have to launch the Java plug-in console and look for the exception/error there. Launching the console is not easy either. Try to explain this to a non-developer. Good luck. It’s also not uncommon for an applet that worked just a second ago to stop working on the next run for unknown reasons.
What I described above is the main reason JavaFX has failed so far. Deployment is still a disaster. If Oracle needs to know how deployment should work, it’s very easy. Just look at Flash. Make it as simple and transparent as running a Flash application. That’s it.
Do I have to learn a new language?
Some people say they don’t like JavaFX because they need to learn a new language. Well that’s just a bunch of hot air. First of all, any decent Java developer can pick up JavaFX Script in about 2 days. And, second, no one is complaining that they have to learn a new language (or scripting language) when they use Flex or Ruby or Scala or even JSF. All require you to learn something new. If you are developer (any kind) today, you have to learn new stuff all the time.
The stuff that’s getting better
Look at any major Java conference for the past two years and you will see at least one session that covers JavaFX. Judging by the blogosphere and Twitter, the JavaFX community is growing. People are posting examples, building custom components, and writing CSS tutorials. The developer community is there. People are trying JavaFX but no organization is building anything real world out there. A medal history application built with JavaFX was deployed during the 2010 Winter Olympics in Vancouver but I doubt many people remember it today. Just recently MLB.com deployed a fantasy baseball application. That’s it.
The argument that JavaFX is missing tools that bridge the designer and developer is a valid one.
JavaFX tooling is being developed. NetBeans has JavaFX Composer (a visual layout tool for building JavaFX applications). Exadel (my company) has been working on Exadel JavaFX Plug-in for Eclipse. Right now, our direction is to provide the most powerful source tools for JavaFX development. Also, IntelliJ just recently announced that it now offers JavaFX support.
The fact that JavaFX is missing many common controls is also a valid argument. New and more advanced controls are actually being developed by the Oracle JavaFX team. Furthermore, to help the community build 3rd-party components, JavaFX should be open sourced.
JavaFX in the enterprise
Enterprise applications such as rich and interactive dashboards and other rich graphical and content user interfaces are a very good candidates for using JavaFX. Enterprise JavaFX has been missing in action. Adobe and its community has done an excellent job demonstrating that Flex can be used to build real-world enterprise applications. The same needs to happen for JavaFX. To help enterprises adopt JavaFX, Exadel has made the Flamingo framework available. Flamingo helps connect the JavaFX UI to enterprise back ends such as Java EE, Spring, and Seam. I personally tried to reach out to Sun and then Oracle on working together on enterprise JavaFX tooling, but, as you might have guessed, I never heard back.
Future?
There is still time to make JavaFX successful, but the time is running out. First, fix the deployment issue as soon as possible. Just start from scratch, don’t try to fix the current deployment system. Second, Oracle needs to make it very clear what its plans are for JavaFX (maybe at JavaOne 2010?). If Oracle doesn’t want or need JavaFX, then open source it and let the community drive it’s future. I think Oracle has 6-12 months at the most to try and revive JavaFX. If nothing happens by then (which would be about 4 years since the technology was announced), we just might as well close the door on JavaFX.
My 2 cents.
Max Katz 
JavaFX was doomed since day one and yes, I saw it and said it.
The reason was not the language, but the company driving it – Sun was a very poor steward of innovation. Sun was successful at creating expectation and then never coming through.
On the other hand, java has always been plagued with configuration and deployment issues. In this age, no one has patience with failing context.
JavaFX’s biggest problem is tooling. The nature and intent of the language demands proximity to designers. No tool, no game. Now, if this tool does not exceed flash tools… you see, the bar is high and the time is not. Netbeans will never, ever, ever, ever, ever! UI design needs to be in the hands of the artists.
If JavaFX will have the tools and the deployment then what? Except for specialized uses, flash is a pest which is disabled by default in my browser.
Frankly what I’m looking for is html5 to deliver. I want to write for the browser, wherever it is, on the desktop or mobile even if functionality is sacrificed.
It is amazing how much effort and money are wasted on a lost cause. I pity companies with such visionaries. They’d not raise the salary of a good programmer, yet they’d waste a fortune on wishful thinking.
Desktop RIA space is saturated. The only way I saw JavaFX thriving was if it was the preferred interface development tool on something other than desktops (tablets, mobiles, TVs, etc). Sun should have gone to bed with Google – but while Adobe Flash running on Android devices is big news, JavaFX hardly gets any mention.
I see a small opportunity with Nokia/Symbion if JavaFX mobile gets in soon. Other than that it looks like a dead end.
Said it before, saying it again: taking over another products market (Flex) is not likely to happen. Trying to get people that are already in your camp to use JavaFX is much easier. Swing is the most used UI platform (according to a news article a few months ago); these are the people Oracle should focus on.
Deployment: there is not much that can be done about the startup speed that is not being attempted (segmentizing the JVM). This process is not done, so improvements may still happen, but it is a full fledged JVM that is brought up.
Applets will never match Flash/Flex, but that also means that Flash/Flex will never match Applets in term of the quality of the JVM that is being started. However, they can make the interaction better; better load status, easier feedback.
Tooling: Groovy and Scala has worse tooling and people are using it anyway. Tooling is not a problem.
New language: as for every new Language like Goovy and Scala. In my opinion JavaFX is as easy as Groovy and after 2 hours not 2 days you can use it! Of course it has advanced features and 2 days is accurate time to learn most of it.
Language: it has closures( will Java7 finaly have it?) and it looks mostly like JSON to me so it is simple and easy to learn. Binding – if you are interested in it.
Deployment: it is disaster, but is anyone now using Java to create Applets?!
Controls: Basic, but writing your own is easier than you think.
One of this two mus be fixed: Deplyment to use JavaFX on websites, or Controls to use it in RichBusiness Applications for Desktops where deployment is a matter of installation or you can even provide .jnlp file.
Why a company or a developper would invest in JavaFx ?
– Right now it’s a failure nobody use it (or look like so)
– If you need a rich client on browser, there is already flash and silverlight. Both share the deployement problem but adress it far better. With javaFx, first time YOU HAVE to download a JVM, then download the applet itself… Nobody will do that if you don’t force them. Like other i use my browser with flashblock. A web site with flash/silverlight/javaFx has a really small chance to have me as a customer.
– flash even has hardware support from GPU. So does HTML in upcomming version of firefox and IE. And JavaFx?
– why introduce a scripting language ? Ok you have ruby, python and all. But just see. Entreprises do not like scripting languages. Yes 1% maybe of developpers have heard of scala, and maybe 0.01% are using it seriouly. Is that the sort of achievement you want for JavaFx ? I’d say javascript is used a lot, but most dev try to avoid it at all cost (doing all on server side, using third party libraries or GWT…). But sucessed because, hey you didn’t have the choice to not use javascript. You want webapp, you have to know javascript.
– Think that javaFx is not CEO friendly, will not work on most phones.
– It’s ten year late, flash is already there, and HTML5 is the future.
– One day or the other Oracle will stop support it.
Deployment is small problem.
Tooling is small problem.
What is main JavaFX problem? In my opinion the vast majority of JavaFXs problems are non-technical. JavaFX needs a leader with a vision.
JavaFX team members isn’t RIA professionals. They just doesn’t understand wgat they should do.
Java applets don’t even work correctly on Mac OS X. When scrolling an html page with an applet, the applet is erased onScroll and then repainted offScroll. That is pathetic! And literally destroys the developer-designer synergy that JavaFX promises to deliver, given nearly all graphic designers use Macs.
As a Swing developer since 1997, don’t even get me started on the never-ending Web Start bugs.
I’ve finally given in, and started learning JavaScript and jQuery (which is actually quite nice).
Oracle should open source JavaFX, and refocus on Swing. But it won’t.
@Nicolas:
“- flash even has hardware support from GPU. So does HTML in upcomming version of firefox and IE. And JavaFx?”
As of 1.3 JavaFX used low level graphics APIs, pixel shaders, etc via its Prism stack. It’s graphics performance is now incredibly good.
“- why introduce a scripting language ? Ok you have ruby, python and all. But just see. Entreprises do not like scripting languages.”
JavaFX Script is not a scripting language. It’s compiled. (Have you even bothered to try JavaFX?)
“- It’s ten year late, flash is already there, and HTML5 is the future.”
HTML 5 is great if you want you app to look like a web page. But some programmers have greater demands than simple CRUD-driven UIs like the kind you find in customer support. Y’know, there *is* a reason why the hottest programming platforms at the moment are iPhone/Android *apps*, not Safari/Webkit. 😉
JavaFX will never ever be a viable browser based solution, and you’re a fool if you think otherwise, period. Where it might have some success in the RIA space is on other devices, phones, etc. But I think that JVM based RIA will never hit it big. Where I think JavaFX could make real inroads however, and I am probably in a minority in thinking this, is on the desktop. It’s a great DSL for GUIs and is so much more painless than writing Swing.
Remember that Swing isn’t used just from Java anymore; there are Clojure, Scala, JRuby, Groovy, etc etc.. Most of these new languages are used by polyglots who appreciate agility in programming, and hence could be great allies in resuscitating JavaFX. What absolutely must happen is proper Java/Swing integration, and fleshing out the reflection API. This will make it much easier to bridge to all of these other languages, and JavaFX could become the universal GUI DSL for the JVM.
Imperative also, is the open-sourcing of the runtime. The runtime API would ideally allow all of the power of JavaFX to be used from any language on the JVM w/o even having to write a line of JavaFX script, and allowing these other languages to define their own more idiomatic abstractions on top of it.
That is how I see JavaFX moving successfully into the future.
I’ve been watching JavaFX for awhile now, and it has seemed to improve at a reasonable pace. The tooling used to be horrendous, but now it is reasonable. The deployment issues have been improved. The problems that you mention used to be common place, but I just went to the samples page at javafx.com (firefox with an up-to-date JVM), and the applets loaded as fast as any Flash applet would. I don’t give Sun/Oracle rave reviews, but they’ve been steadily moving JavaFX in the right direction. So the downsides of JavaFX are being addressed and will eventually be non-issues. Once that is the case the benefits of JavaFX will still remain.
JavaFX seems well suitable to demonstrate and illustrate some information interactively; something where people still use Java applets even now. It provides some scene-bound concept that is great for the small illustrative application (may not be so great in a bigger project), and they “bindings” at least look more more nice as various listeners that standard Java uses for this purpose. The most impressive Java applets are likely educational Java applets written by people who are competent in the areas they illustrate, not in Java programming. However it is not clear if the existing mass of educational applets will be ever rewritten in JavaFX. They development have peaked twice, one long in the past (when applets were on the wave) and second time recently when Java has been open sourced, and many projects are quite dormant at the moment.
Our ~1.5yr JavaFX experience was both brilliant and frustrating. Here’s me 2c…
The good stuff:
Bind – just awesomely powerful!
Scene/Graph and styling (you don’t need a layout manager when its this simple, just blows swing out of the water).
Media (show me this in swing or JMF, I think NOT).
EDT (Event Driven Thread – swing really got this wrong from the get go).
The bad stuff (points):
-Applet’s were horrible (as above).
-Mobile device… ummm what mobile device? There wasn’t one!
-Desktop/Swing, was an extremely distant consideration and what I believe to be the most critical flaw.
-Netbeans lacked some basic features (like refactor/move/rename/references e.t.c.).
-Eclipse support (I’m happy to jump between IDE’s but I’m in the minority).
In detail:
Applets never worked and JavaFX mobiles never existed – this kills 2/3 platforms. Granted these two platforms are hard to crack and you’d have hoped sun would have recognised this. The desktop didn’t really get any serious attention from Sun (now oracle). Java’s closest parallel to JavaFX was Swing. But integration of JavaFX INTO a swing application didn’t exist. Consequently the easiest market to adopt JavaFX couldn’t… seriously bad and killed the 3rd platform!
Other problems include the distro license also prevented easy roll out of apps, as did the JavaFX/Java desktop runtime isolation. Hacking/Patching the JVM with the JavaFX dll/so’s and jars to use JavaFX FROM java was the only way to get the full JVM with JavaFX’s runtime, and that’s a pretty substantial hack! Another personal gripe was the difference between java’s autoboxing and javafx’s default values (null is there for a REALLY IMPORTANT reason).
Summary IMHO:
All in all, there were brilliant language features in JavaFX and it really highlighted serious deficiencies in Java. “Holy Grail” markets (i.e. mobile and web) were targeted with associated high risk rather than reliable grass roots markets. This risk proved to great a challenge 😥
I agree that the JavaFX from the get go was not very easy to adapt especially if you are core java developer and has been developing GUIs in Swing.
But I think to compare it strictly to web based technologies is not justified in my mind. There are not any technologies currently that allow you to develop cross platform desktop application except for Swing and JavaFX.
I think the new roadmap for FX announced by Oracle is perfect. We will be able to leverage Swing into next level of apps (desktop) with FX.
With all the power of multi-core hardware to tap, memory and garbage control and concurrent programming, there won’t be any competitive technology in that space. As for deployment goes all they have to do is work out the kinks in java web start which is not too, bad (I have used it in production environments for a long time)
Indeed very true… being exploring javaFX of late … initially it looked quite promising until I got to the deployment part. And your blog has just confirmed. I would rather wait than to get my hands burned. Thanks again
I think it’s a good technology and it’s needed, but must change the deployment issue and maybe change its future to html5/javascript env.
Javascript and its way to do OOP sucks, it’s powerful but lacks of all the good stuff
What you can do now in in HTML 5 canvas and JS it’s awesome, but coding it it’s no fun. we need a new env I guess there’s a future for JavaFX we need to push it further. Oracle needs to learn from Adobe an their future for Flash.
@Digital: For HTML5 tools, check out Tiggzi – http://tiggzi.com. Tiggzi is a cloud-based HTML5, jQuery Mobile and PhoneGap mobile app builder. It’s incredibly fast to build mobile apps connected to REST services.
Thanks Max, I know the tools but debugging it’s awful. I’m a Java Dev. front and back end. Im writing a game engine in JS at the moment from scratch, I know there aleready engines too but I found very rewarding writing your own stuff, I sue Jquery though.
Regards
Digital Mee
Hi Max,
I see that this post is quite old. What do you think of JavaFX now ? I am actually working on a software which is written in Java Swing and I need to re-design it. Since JavaFX provides more flexibility etc. I am thinking to migrate the software from Java Swing to JavaFX.
Hi – I haven’t been involved with JavaFX for many year so… it’s best to ask the JavaFX community. I think it’s a very niche tool to build some very specific applications.