Max Katz

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.