Is the Expansion of JavaFX Too Late?
JavaFX will be getting some more spotlight at this year's JavaONE conference. But is it too little, too late? A year has passed since the initial announcement, and now developers are to be treated with a selection of new profiles in JavaFX.
JavaFX Architecture
The list of profiles is both predictable and sensible, with JavaFX Desktop and JavaFX Mobile as the main players, along with profiles for phones and set top boxes. These profiles won't all be released simultaneously as there are some outstanding issues to be resolved with the APIs which should be provided. The NetBeans platform will be leveraged to provide tools for creating JavaFX applications.
Given the original plans for the Java language in general, shouldn't this have been something that was covered straight away with the release of JavaFX. Apparently, the profiles will not obstruct the aims of JavaME, but will sit on top of the micro edition architecture and eventually merge.
It's difficult to see JavaFX as a true RIA contender to Adobe AIR and Microsoft's Silverlight. But it's good to be hopeful. In an Infoworld article Ed Klein, VP of marketting at Sun, claims that users have been waiting for Java to enter the RIA market in full force and that Java is to be the platform for the screens of your life.
What do you think? Can JavaFX become the standard choice for RIA development? Are the profiles too late in an already crowded RIA space?
James is a DZone Zone Leader and has posted 228 posts at DZone. You can read more from them at their website.
- Login or register to post comments
- 5699 reads
- Printer-friendly version
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
Roger Voss replied on Sun, 2008/04/27 - 9:47pm
in response to: jas_ejb
I suspect JavaFX will get a big uptick in adoption among Java devs once it goes gold, for the same reasons the .Net guy just reasoned that Silverlight will get a big uptick in adoption among .Net devs.
And personally, for serious application development I'll take the JVM or the .Net CLR over Flash for my runtime of choice any day of the week. Flash is outstanding for bling, animation, multimedia content, and games - those were things it was designed for. Flex is very very nice, and is easy to work with, and makes Flash better for business applications. However, it's not a full platform/runtime like the JVM or the .Net CLR.
But for serious apps, where multithreading comes into play, and the need for a diverse set of libraries, you need a full platform/runtime like the JVM or .Net CLR.
Also, don't underestimate the importance of tools. I hear that FlexBuilder is outstanding. But it's expensive, and I won't buy it unless my work requires using Flex and I need the extra productivity. By contrast, NetBeans is completely free, and an extremely powerful IDE with tons of features. And, NetBeans has a free JavaFX plugin.
[/quote]
That's exactly it - Flex and Flash Player runtime are more precisely tuned for adequacy for building the greatest majority of business apps. The apps that need the full range of capability of JVM or .NET CLR are edge cases. So Flash has a runtime that downloads as less than 3 megabytes instead of amounting to 16 megabytes as does the JRE.
With the model of Flex async i/o and ActionScript3 closures, a single threaded GUI programming model works out very well indeed. For business applications it's actually better than a multi-threading approach. In Flex one can still put up progress indicators with cancel buttons while an i/o operation takes place asynchronously. A Flex app can be designed to be very UI responsive to the user at all times even with just a single threaded programming model.
With Adobe AIR there is still yet a different approach for background processing task, which is modeled on the Google Gears worker thread pool. This thread pool is interacted with via messaging and avoids the greater complexity problem of thread synchronization APIs that .NET and Java resort to.
For systems programming of server-side application servers, .NET CLR and Java JVM multi-threading approach is what you want.
For business application programming, the entire Flex/AIR approach of async IO, language level closure feature, and messaging-based worker thread pools, is the much superior way to go as it will be easier for large enterprise teams of business app programmers to turn out user responsive applications that are bug free (when it come to multi-threaded concurrency issues). Plus they'll be able to write that manner of software much quicker than having to stoop to .NET or Java style multi-threaded programming.
IOW, .NET and JVM multi-threading is actually going to be a significant liability for web RIA application development - not a positive asset.
That's really it in a nutshell. Adobe has very well tuned the capabilities of Flex for what is really needed in web RIA app development. Microsoft and Sun both don't groc that equation nearly as well.
What Silverlight 2.0 .NET CLR and Java JVM are bringing to the table are essentially things that are superfluous. In addition to multi-threading, Silverlight folks are making noise about multiple language feature. Here again Flex ActionScript3 and MXML are so well tuned and easy to learn for any existing C# or Java developer that this too is a complete non-issue. The experience of my staff that have taken up Flex development is that they have universally liked MXML and AS3. One developer did his first Flex app, a google-like search tool with an interactive data grid, in three hours. Another developer had struggled for days to do something comparable using Java and GWT. The GWT solution never came close to the full richness of the Flex solution (it was a tipping point that well illustrated to us that GWT was definitely not the future of RIA).
As to Flex Builder - Adobe provides it as an Eclipse plugin too. That's the way I install it. I download the latest Eclipse IDE, install Flex Builder plugin, as well as all the other plugins I like to use. I have other staff that use the Flex Builder and Netbeans in combo, doing Flex in one and Java middle-tier in the other.
The pricing is two tier. For $300 you get the basic Flex Builder. For $700 you get Flex Builder, chart library (for data visualization), and automation classes. This latter feature can be combined with RIATest to enable QA staff to do scripted test of Flex app UI. The chart library alone is very much worth the price as it is an astounding library.
One can always do Flex development with just the Flex SDK as well - all of our projects compile entirely from the command line using ant.
Relative to pricing for the full stack that would be needed from Microsoft to do Silverlight development, the Adobe pricing of the Flex builder is entirely reasonable. And with JavaFX there is no charting library and automation solution out of the box - despite the tool stack could potentially be free. Believe me - everybody doing serious work is going to want the charting library and automation classes. These kind of things just by themselves make Silverlight and JavaFX non-starters.
Of course I'm looking at this from the perspective of solving real world business problems and not entirely from a developer's perspective (though I don't ignore that by any means). It's the fact that Flex is a much richer solution to match up to real world needs of developing enterprise business software that makes it so compelling. Developers get strung along with interest in Silverlight and JavaFX because they myopically focus on less relevant programming geek issues.
--RogerV
"Let me get right to it by lobbing some grenades: I recognize two arch evils in the software universe – synchronous RPC and remoted interfaces of distributed objects."
neatisca replied on Sat, 2008/04/26 - 8:45pm
in response to: jas_ejb
I agree w/ you, Jeffs. Adobe can certainly claim Flex is ahead of SilverLight and JavaFX, but that's mostly on the presentation tier. Web apps are typically 3-tier programs that more often than not require strong, proven technique at each layer which is the traditional strength of both .Net and J2EE solution packages. This reason alone keeps the majority of .Net/J2EE developers glued to their own camp. For .Net developers, w/ WCF & SqlServer sitting at the other two layers SilverLight blends in easily as the presentation layer. You too would expect JavaFX works just fine w/ existing J2EE framework. Adobe seems to have some of their own backend packages. We'll see how well they compete w/ M$ and Sun in that aspect.
Roger Voss replied on Sun, 2008/04/27 - 9:30pm
in response to: neatisca
Adobe offers ColdFusion for a server-side solution to use with Flex and they also have a drop-in component, LiveCycleDataServices (LCDS) for JEE servers. It's a messaging-based RAD middle-ware component.
However, when Flex 3 and AIR 1.0 shipped as final release bits in Feburary of this year, Adobe also released the first non-beta iteration of an open source component called BlazeDS.
BlazeDS supports asyncronous remoting from Flex apps and bi-directional messaging. It takes care of marshalling of data transfer objects between ActionScript3 and Java - uses AMF as an over-the-wire format, which Adobe also opened up documentation for. BlazeDS uses HTTP and the Comet Pattern for server-side message push, so can work over ports 80/443 of existing firewall configurations.
For Flex projects that I oversee my teams have devised an awesome 100% open source stack for the server-side (from bottom toward top):
With the way BlazeDS is wired in, we use Spring POJO beans to handle BlazeDS remoting, Spring Controllers enable using Spring POJOs to handle HTTP services such as GET/POST/PUT, and using Spring JMS template classes we also wire Spring POJOs to process ActiveMQ JMS messaging. Spring security is applied uniformly across all these context.
Flex-based web RIA clients coupled to this 100% open source server-side stack has been the most awesome architecture I've had the pleasure of devising in my career (spanning back to 1986, when started out professionally as a Macintosh MPW programmer using 68000 ASM, C, and Object Pascal).
I've always despised HTML/JavaScript web 1.0 for use in devising business apps as is an atrocious programming model, and doing MVC on the server-side is architectually wrong-headed as goes against the grain of:
Fallacies of Distributed Computing
http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing
With Flex-based web RIA (where MVC is strictly on the client-tier and simple SOA on the middle-tier) I've finally encountered a programming model I can truly admire and relish in.
Mr Magoo replied on Sun, 2008/04/27 - 8:24pm
To answer the question in the title: Is the expansion of JavaFx too late?
I think there is consensus on the naive version of this question: "Yes, very."
JavaFX should have been in java looooooonnnnngggg before now as should any supporting technologies. The vacum created by its absence is the one part of the java world that has made me embarrassed to be a java developer. (There, I said it)
The great "fall of Applet Empire" was the first embarrasement that led to this vacum and has since continued. And please, no applet games examples as if that was proof of Applet success!! That is like saying toga parties are evidence of the continued success of the greek or roman empire!!
Whether it is too late to be adpoted and compete against its (well entrenched?) competitors in the market?? I don't think anybody is qualified to answer that question.
I could be wrong. There may be some IT trained psychic out there somewhere....?!
Weiqi Gao replied on Sun, 2008/04/27 - 10:49pm
Roger,
I agree with all your assessments: the inadequacy and awkwardness of the HTML/Javascript/CSS programing model, the (at the moment) superiority of Flex over its rivals from Microsoft and Sun, and the freedom that Java developers have in just adopting Flex rather than waiting for JavaFX Script.
What I don't agree with you is your (seeming) implication that because Adobe is currently the leader in RIA tools, somehow Sun and Microsoft should not create their own tools or that their tools will never catch up with Adobe's offerings.
Let those who can afford to start with (or switch to) Flex do so. Let who cannot afford the adoption or switch stay with their current technologies and hope that in due course the alternatives from Microsoft or Sun will catch up so that when the time comes to start their RIA applications they don't need to do the big switch.
My belief is that Microsoft and Sun are capable to create tools that will achieve parity with Adobe's tools. I also believe the market place is big enough to have three viable set of tools, each serving their respective development communities well.
Mark Thornton replied on Mon, 2008/04/28 - 6:02am
in response to: rv49649
[quote=rv49649]So Flash has a runtime that downloads as less than 3 megabytes instead of amounting to 16 megabytes as does the JRE.[/quote]
The online JRE download is typically rather less at around 10MB. The offline installer contains an update for Microsoft's Windows Installer which most people don't need.
JeffS replied on Mon, 2008/04/28 - 11:55am
in response to: mrshanepaul
The great "fall of Applet Empire" was the first embarrasement that led to this vacum and has since continued. And please, no applet games examples as if that was proof of Applet success!! That is like saying toga parties are evidence of the continued success of the greek or roman empire!!
[/quote]
Great line, and so true. :-)
JeffS replied on Mon, 2008/04/28 - 11:59am
in response to: rv49649
That's exactly it - Flex and Flash Player runtime are more precisely tuned for adequacy for building the greatest majority of business apps. The apps that need the full range of capability of JVM or .NET CLR are edge cases. So Flash has a runtime that downloads as less than 3 megabytes instead of amounting to 16 megabytes as does the JRE.
With the model of Flex async i/o and ActionScript3 closures, a single threaded GUI programming model works out very well indeed. For business applications it's actually better than a multi-threading approach. In Flex one can still put up progress indicators with cancel buttons while an i/o operation takes place asynchronously. A Flex app can be designed to be very UI responsive to the user at all times even with just a single threaded programming model.
With Adobe AIR there is still yet a different approach for background processing task, which is modeled on the Google Gears worker thread pool. This thread pool is interacted with via messaging and avoids the greater complexity problem of thread synchronization APIs that .NET and Java resort to.
For systems programming of server-side application servers, .NET CLR and Java JVM multi-threading approach is what you want.
For business application programming, the entire Flex/AIR approach of async IO, language level closure feature, and messaging-based worker thread pools, is the much superior way to go as it will be easier for large enterprise teams of business app programmers to turn out user responsive applications that are bug free (when it come to multi-threaded concurrency issues). Plus they'll be able to write that manner of software much quicker than having to stoop to .NET or Java style multi-threaded programming.
IOW, .NET and JVM multi-threading is actually going to be a significant liability for web RIA application development - not a positive asset.
That's really it in a nutshell. Adobe has very well tuned the capabilities of Flex for what is really needed in web RIA app development. Microsoft and Sun both don't groc that equation nearly as well.
[/quote]
That sounds really good, actually. I did not know that Flash/Flex was doing that. And I have always liked the idea of asynchrous messaging. And, multi-threaded coding can be a PITA, and having to be really good at it (or, at least knowledgable and competent) is a weakness of Swing. It's not that you can't make great looking, fast, responsive GUIs with Swing, it's that it requires some real know-how and skill (not that that is a bad thing unto itself, but it's never good for their to be such challenges).
neatisca replied on Mon, 2008/04/28 - 5:18pm
in response to: rv49649
IOW, .NET and JVM multi-threading is actually going to be a significant liability for web RIA application development - not a positive asset.
That's really it in a nutshell. Adobe has very well tuned the capabilities of Flex for what is really needed in web RIA app development. Microsoft and Sun both don't groc that equation nearly as well.
What Silverlight 2.0 .NET CLR and Java JVM are bringing to the table are essentially things that are superfluous.
--RogerV
[/quote]
That's an interesting take. M$ realized (painstakingly) a while ago that online web apps will eliminate their OS dominance so they designed SilverLight from ground up as a serious application platform that tries to bring their desktop apps online, which is why they've been putting in SL seemingly overkill features such as multithreading. If you just want to replace the clumsy Ajax-based web apps, then Flex is spot on. But if you look forward to full-fledged desktop apps running online, then it's natural to ask for a "superfluous" RIA platform. After all, why not utilize the client-side computing power to the fullest? That's the root cause why we find AJAX inadequate to begin with. My guess is Google would love to have their own SL so that Google Docs for example would be a competitive alternative rather than the currently laughable Office-wannabe.M$ started out this compaign by first replacing their WinFrom (.Net version of Java Swing) with WPF which is a XAML-based. After that, they've been examining the WPF bits and decide which to fit in SL. It takes a while but it's worthy effort in the right direction for them, and they are moving further in that direction. IMO, SL2 is not "superfluous" enough yet since it has to fit in the execution environment of a browser. It's interesting to see how good SL will be once it is set fully free.
neatisca replied on Tue, 2008/04/29 - 12:43pm
Secondly, is strong threading support unnecessary in SL2? I don't think so. If in a RIA I run multiple video sessions for online live meeting, stock tracers or animations, I'd like to put them in different threads and have hand-on control so that I can change their priority and preemptively suspend, sleep, resume or abort them. And what if I want to code a non-trivial online game that does require strong threading support? The ability to run and fine-tune multiple threads is important for those tasks. The current web apps are so handicapped by HTML/AJAX that people think they are not supposed to do more than reading emails, checking bank account or watching Youtube. W/ RIA maturing, people would start to ask for more. What seems to be enough today for business application today will change down the road.
Also I wanna emphasize a point I made before: A RIA platform should utilize the client-side computing power to the fullest. Look at the platform we have here: On the software side, we have Windows, OS/X and Linux. All provide powerful threading support. On the hardware side, CPUS are moving to the multi-core age unleashing further threading and computing power. The gain from parallel computing definitely out-weighs the programming pain. If RIAs are to run software as services in future, they are suppose to ride on the trend instead of skipping it.
Roger Voss replied on Wed, 2008/04/30 - 3:34am
in response to: neatisca
These kind arguments all sound pretty much the same as the ones made by Microsoft when it first introduced ActiveX controls for web page enhancement. That resulted in unleashing multiple years of agony of buggy and/or malicious invaders into one's machine via the web page. It was one of the very worst ideas Microsoft ever foisted on so much of humanity.
I rather much appreciate how web RIA, as exemplified by Flex and AIR, is carefully corralled in capabilities and sandboxing. Folks can feel pretty darn comfortable with Flex apps because of that.
I really don't want to start hitting web pages that contain multi-threaded Silverlight objects that were rushed to market with more emphasis on glitz than on QA for robustness/correctness. That will just be the ActiveX experience all over again. No thank you.
Weiqi Gao replied on Wed, 2008/04/30 - 7:10am
JavaFX Script, unlike Silverlight, is a single threaded language with the ability to dispatch work to a working thread whose creation the programmer does not control. It offers a simple programming model. When it's done, it will be much like what Flex AIR is, with the additional benefit that the whole thing, including the runtime, is open source and it will support browser based applications as well as desktop applications and mobile, settop device applications.
Yes, it runs inside the JVM and if the programmer want to, he can create Java threads or even do a bit of Swing programming. But that's not the exposed model and will probably be counter productive.
I'm eager to see what kind of JavaFX stuff will be shown in this years JavaOne next week.
neatisca replied on Wed, 2008/04/30 - 9:21am
Flash has had secrity problems for years in the first place. I remember just last December Flash has been reported vulnerable to cross-site script attack b/c of a design flaw in Shockwave format. In the hacking contest early last March, another Flash "zero-day" vulnerability was exposed, ain't it? It'd be funny if Adobe thinks they have bragging right over M$ about security.
And I do think features like generics, multithreading and so on underlines a company's ability at developing a capable run-time platform. I think Adobe would love to have them in Flex than not.
Now this open source thing, good for you if you believe it. I myself haven't figured out how "open" automatically results in "good". Google doesn't need to open source their search engine to be the best of the filed, Oracle / IBM don't on their DB servers either, nor does Adobe on its PhotoShop suite. I think if a product is good then it's good. Open or not doesn't make a whole lot of difference.