Guest post by Nearly three years after its introduction, the JavaFX multimedia application development platform that Oracle inherited from Sun remains just another entrant in a crowded field, with questions looming about how much momentum the platform can gather. With a debut that saw JavaFX trailing behind RIA technologies such as Adobe Flash, Microsoft Silverlight, and AJAX and the emergence of HTML5, some view JavaFX on the ropes, despite Oracle’s claims of commitment to the technology. “It’s superior [to rival technologies], but maybe that doesn’t count anymore,” says the chair of one Java Special Interest Group. Red Hat CTO of Middleware Mark Little echoed the skepticism building around JavaFX’s future, saying that at this stage, JavaFX will survive only if Oracle can build a business around it. “Otherwise, it will die.”
Definitely too late, but then, it was pretty much dead on arrival. Sun announced it, released it, and then did nothing more to promote it.
Not that it ever really had a chance anyway. Flash and AJAX had the advantage of being ubiquitous web platforms already, and they’re still dominating. Silverlight has serious backing from Microsoft, and the advantage of being a ‘native’ API on Windows. But on the client, Java has nothing.
They actually did do a bit to promote it, but the thing is, when they released it it was still only half-cooked. So they couldn’t in good conscience tell everyone to start using it right away when it was in fact still an unfinished, buggy thing with non-finalized APIs.
With JavaFX 1.2 the situation was improved enormously, to the point where I can actually recommend it to people. And I’m not shy about it, because as they say, “the right tool for the job”. The fact is that the Java platform has more open-source libraries than any other platform I know of, which for many projects makes it a very sensible choice. And having made that choice, JavaFX is a very sensible way to build the UI. It doesn’t have to compete with Flash and Silverlight on the web to be able to keep that advantage.
I am a big fan of JavaFX and have had success doing some prototyping work using it. However, there are a lot of problems Oracle still needs to solve:
1) Toolset: The NetBeans plugin is very buggy, and the Eclipse plugin is just plain sucky. Basically if you’re serious about developing using JavaFX it’s a joke to try to use Eclipse, because you don’t even get the most basic features like jumping to variable declaration, code autoformatting, refactoring, autocompletion, automatic import… *nothing*. On the other hand, the NetBeans plugin has its own issues like random slowdowns/freezes, inexplicable “parser exceptions” which leads to files being marked as having errors when they don’t, and random inability to recognize external JARs that were added to the project. Meanwhile, even the compiler crashes on the odd bits of code once in a while. Finally, the visual designer that’s currently in beta is unusable–you can’t use it on existing fx files, only ones you specially create with the designer in mind, and when you create these files it (in my experience) just causes the entire NetBeans IDE to freeze/crash. And the thing is, the visual designer and plugins actually need to be more or less *flawless* in the next release if JavaFX is to compete with the likes of Flex and Silverlight.
2) Stable API. I get it that it’s a young platform, but do you see Microsoft or Adobe making drastic changes to their APIs in point releases? No, and there’s a reason why not: because it’s a PITA for developers. It may somehow work for OSS, but for commercial customers it is terrible. Sometime soon the JavaFX managers had better call an API freeze, otherwise the cycle of broken applications will never end.
3) Better Java integration. If JavaFX components could be integrated into Swing applications (rather than only the other way around) I have a feeling there would be a lot more adopters. Likewise, users should be able to easily define/modify JavaFX nodes using the Java language instead of being forced to use JavaFX script for everything.
4) Fix the plugin support on the Mac. It sucks, especially when compared side-by-side with the newest Windows plugin. It takes forever for the plugin to load, sometimes it causes the browser to crash for no reason, and the applet has a habit of temporarily disappearing whenever you scroll the page.
5) Actually deliver on the mobile platform promise. Millions of Android, Blackberry, Symbian and other devices are just waiting for JavaFX support. Right now it’s not fulfilling its promise of “run anywhere”, instead it’s more like “run on Windows Mobile and… uh… yeah, that was it.” Plus who knows whether Windows Phone 7 will even support it?
6) Add multitouch capabilities to the API. Microsoft, Adobe, Google, and Qt all support multitouch now–it’s time for JavaFX to get in the game.
7) We keep hearing about the JavaFX TV platform and how it will revolutionize Bluray authoring. I believe it could–if the day ever comes when the Bluray platform gets an updated Java spec….
8) Open-source it and port it to Linux. The port to Linux has always been promised; now it’s time to deliver. Without Linux a huge segment of potential developers and users is being ignored. And without it being open-source it can’t be included in distros.
9) Get the act together on Java Media Components. It needs to work flawlessly with, at the very least, Ogg Vorbis (as was promised) and be easily usable from Java as well as JavaFX Script. And really, it should be part of Java SE 7.
So, it’s a monster list, but many of these things were promised by Sun more or less as I have described them, and all of them are necessary if Oracle is serious about the future of the JavaFX platform.
I know that mergers are a painful process that often leads to serious lost productivity for months or years after they happen, but this is one case where Oracle should really just interfere as minimally as possible, while adding as much financial and manpower resources as possible, until the next release is out the door. Otherwise JavaFX will never be able to overcome its growing pains and instead of blossoming it will whither before its time.
Add to that there is no video encoder included if you wish to develop – to support the video format used, VP8, you will have to shell out at least $200 for it (minimum) which doesn’t include the fact that the encoder doesn’t work on alternative platforms. So you’ve got something put up as an alternative that supports two free formats that can’t compete with h264 and an obscure proprietary format whose encoder isn’t included as part of the SDK. Little wonder bright ideas like JavaFX resulted in them begging to bought out.
I still wonder why Java Applets went out of fashion. It was very easy to make interactive web applications way before Ajax and Javascript toolsets were all the rage. They were very easy to write, and you could easily add animations. Then one day we all decided (well, not everyone) that Applets were the suck and welcomed the Flash god.
I play Yahoo fantasy sports, and I loved their Java Stattracker applet. It was lean and clean, I could run it on a 233mhz Pentium 1, Then one day they switched to Flash, which was huge, garish, and required incredible cpu resources. I just wonder why??
Applets on one hand offered too much at the time (a full fledged runtime environment), which made them slow to start, on the other, they were missing some “flashy” (pun intended) features, like animation, vector graphic, multimedia frameworks etc. Plus integration with browsers sucked – starting an applet caused the browser to hang until the JRE is up and running. There were no content authoring tools etc.
Perhaps Oracle should open-source JavaFX and talk to guys like Mozilla or Chromium to have it included in their browsers. If they could then go beyond the plugin form-factor that would be great for the user experience (I’d love the embedded app to integrate with the browser’s back button, have a text selection capability, have an ability to access&modify arbitrary parts of the website etc.).
-The Java VM was (and is) SLOW. Even the latest VM versions will hang your browser for a while while the whole thing loads. I can tell that I’m loading a Java apple just by hearing the disk noise and noticing how unresponsive becomes the whole system suddenly. Flash is much faster.
-Lack of native widgets appearance for too much time. Java apps were ugly…
-Applets were designed to write generic Java apps. Flash is designed for web apps. Sun designed Java applets with enterprises in mind, they didn’t care about web developers – Flash, in the other hand, only cared about web developers.
JavaFX is dead since it’s beginning. The complexity mentality of Java things doens’t match with the mind of the “cool guys” of web development.
I think QML has a much better chance with all the Nokia money and all:
http://labs.trolltech.com/blogs/2009/05/13/qt-declarative-ui/
nice demo… but that chopper finger creeps the sh1t out of me
QML has the advantage that is a seriously “emerging” technology – not something that tried and failed. Even the core language itself is just being hammered down.
It also doesn’t make the pretense of being a browser technology. It’s just a better way of doing fast & fluid applications, with clear and documented way of escaping to C++ Qt code where it makes sense.
Duh.
It was a “me too” that was “too late”.
It isn’t superior, I’ve had it crash my browser numerous times.
define succeed. Will it gain majority control of the web technology? no. will it catch on to the point of becoming relevant in your every day life? no. will it exist to a point that it does have its uses and there by justifies its existence? yes.
There is poor Swing integration and the reliance on webstart makes it impossible to use in most rich clients.
I think it has a future as a successor to swing if the upgrade path is smooth enough and the api is easy to use.
I’ve seen worse technologies reinvent themselves completely and turn out to be really good.
This is from a Silverlight guy. Complacency is never a good thing.
I think it’s extremely unlikely, but it has a lot of catching up to do if it does happen.