|
Mar 02
2009
|
  |
 |
JavaFX (javafx.com), a rich client platform that makes building GUI applications for the desktop and mobile spaces quite easy, was launched as version 1.0 in December of 2008. Since then, there have been over 100,000,000 downloads of the tools and the SDK. And since JavaFX is integrated with Java SE (both JDK and JRE) it's ready to go on over 50 million desktops.
JavaFX is composed of the compiler, runtime tools, and libraries for graphics, media, text, and web service support. Its goal is to allow you to build one application with one set of source code that runs equally well on desktops, mobile devices, and TVs. A mobile emulator is included to allow you to target mobile devices with differing screen real-estate. One of the coolest features is the ability to embed JavaFX applications into web pages, and then tear them off the page and onto the desktop where they can live outside the browser.
In terms of development tools, there's an excellent environment available as part of NetBeans 6.5 (http://javafx.com/downloads), and there's even a plug-in available for Eclipse (http://kenai.com/projects/eplugin). I've been working with them quite a bit lately and they work well. With JavaFX 1.1, released recently, there are now plugins and tools available for graphic artists, integrating with Adobe Photoshop and Illustrator CS3. There's also the new Media Factory that can convert media in many forms into JavaFX Scrip code, automatically.
JavaFX Mobile
The overall goal of JavaFX Mobile is to provide a unified environment for mobile device manufacturers, as well as mobile application developers. For manufacturers, this means one runtime environment for all of their devices that work equally well, without the need to build many of the features that JavaFX mobile will provide. This includes filesystem support, GPS support, bluetooth, networking, graphics displays, and so on. It's not a far stretch to consider JavaFX as a mobile OS all its own.
For developers, once again, JavaFX Mobile provides a runtime environment that supports many of the same paradigms seen on the desktop. It also allows you to maintain one source code tree, where the runtime takes care of adjusting the display for you based on the target device's capabilities. This greatly increases the market for your Java desktop applications, as Java runs on literally billions of devices.
In the future, I would expect to see JavaFX Mobile running on devices such as the upcoming Palm Pre, Apple's iPhone, Android, and Microsoft Windows Mobile, although support for these platforms have not been officially announced by Sun. I would also expect to see, based on what Sun is saying, that JavaFX Mobile will run on less-capable devices, acting as the OS itself.
JavaFX Script
To be prepared, as a Java developer, you should focus on the language: JavaFX Script. It works with Java, and you can mix the two languages together. After some getting used to, you'll find yourself building rich GUI applications with little time, effort, and code. This separates it from Java Swing, which requires a little more effort and more code to accomplish many of the same things. Sun, however, is maintaining that Swing is not going away. This is a question I hear in the context of JavaFX versus Swing, and there appears to be room for both to coexist. Instead, JavaFX Script is focused on being an alternative to JavaScript, Adobe ActionScript, and Microsoft Silverlight.
For more information on JavaFX Script programming, you can check out the following resources:
-JavaFX Site: http://www.javafx.com
-Chris Oliver's blog: http://blogs.sun.com/chrisoliver/
-JavaFX: Developing Rich Internet Applications: http://www.jfxbook.com
As for the roadmap for JavaFX, I would expect to see some exciting tools announcements at JavaOne this year aimed at graphic artists and others interested in building rich media applications. After that, we should hear more about JavaFX TV.
It's an exciting time to be a Java developer, as it gets easier to build media-rich applications that run on desktops, mobile devices, and (in the future) TV. All we need now is a JavaFX Application Store that will target the billions of devices already running Java! How's that for market opportunity? Hopefully Sun is reading this ;-)
Happy coding!
-EJB
Subscribe to this comment's feed
Show/Hide commentswritten by Eric Bruno, March 04, 2009
Finally, the coolness of being able to drag a JavaFX application off of a web page and onto a desktop is that it makes for an easy deployment. No install mess. I find that cool. Others might also.
All that being said, of course nothing is perfect, and JavaFX is no exception. Please continue to choose the technologies you like best. If you don't like JavaFX that's fine. But as a Java developer, I find some things about it interesting, and thought I should share it.
written by ranjix _, March 04, 2009
Android is not "Java" in the same way that J2ME with the different profiles is not "Java" (different libs, different JVMs, same programming language). The fragmentation (not in the legal way) already exists. On the same line, I don't really see JavaFX being Java. The language is different, as simple as it might be, so you still need "experts" in various areas, just like you need with the JavaScript and HTML. Also, the development for desktop is different than the one for mobile devices, so again you need the different "experts".
Personally I would like to see that JavaFX succeeds where J2ME didn't, but one has to wonder why after so many years of J2ME, a device like iPhone doesn't support Java...
written by Eric Bruno, March 04, 2009
As far as I know, Apple is not allowing any form of VM or environment on the iPhone because they want to retain total control over the platform. Supposedly they're working with Adobe to get Flash support, but it hasn't happened yet so it could be a rumor. I don't have insight into any of this so I can only guess what's going to happen.
written by ranjix _, March 04, 2009
). So, it looks to me like the whole focus of JavaFX goes in the wrong direction, as long as they even have a notion of "JavaFX Mobile", suggesting that is different than the "regular" one. So, as long as they don't completely hide that difference (don't ask me how, I would answer "intelligently"), there will be room for vast improvement. Right now IMO JavaFX attacks a superficial problem - "make the UI more accessible for designers" - when actually the problem is in making the UI better altogether. And it attacks this issue by inventing a new language. Great. 
written by Bryan Kitts, March 06, 2009
Since then, there have been over 100,000,000 downloads of the tools and the SDK
100 million downloads of the SDK? It seems extremely unlikely that there are 100 million Java developers in the world. Where do you get this figure from?
written by Eric Bruno, March 07, 2009
Actually, he said runtimes, so I could have been more accurate. But at this point, there are more than likely the same.
Show/Hide comment form
Second, Android seems to ride the other "cool" (let's see how long it lasts) wave, which is Google itself. Sure, is Java based, but not JavaFX.
With the 2 above, don't see too much space to turn for JavaFX, maybe to fight the battle with Silverlight for the niche/Zune type of devices.
Third, after trying JavaFX (2 times, thinking maybe the first it/I was too immature), I found it being a weirdo. Sure, it replaces some Swing, but without knowing some Swing you don't get anywhere. On top of that, the declarative type of UI definition is not very "framework-able", which I perceive as being a drawback next to Swing. The only possible advantage of JavaFX over Swing is the "more" rapid UI prototyping and some effects which not sure had a place in the Java UIs in the first place. Maybe they do. Unfortunately, IMO the advantage is balanced by the new "scripting language" and by complicating the process. Also, not sure how seriously we should take the media in JavaFX, considering the previous (IMO) failed experiment, JMF.
So, if I had a choice, I would go the following ways:
- for small, light processing, "cool" web UI - JavaScript.
- for small, very graphical web UIs, Flash.
- for heavier apps on the client (processing + storage), a standalone or a web start. I don't really see why a heavier app would be integrated in an HTML page.
Also, if I add GWT and Gears, I can see that heavier apps could be done just as well in JavaScript.
Finally, I absolutely fail to see the coolness of dragging an applet to make it a desktop app.