RIA Zone - Comments for "Is the Expansion of JavaFX Too Late?"

Flash Player has had a

rv49649 — Wed, 30 Apr 2008 22:29:01 -0400

Flash Player has had a number of years for vulnerabilities to be exposed and hammered down. With the Silverlight runtime it will be green pastures in that department all over again.

I'm not super idealogical about the open source issue - but I will say that SpringSource has got the best thing going for enterprise server-side development. It's an architect's and developer's delight.

Alas Spring.NET is the Spring family poor cousin - perhaps better than nothing - but the Java-based Spring is much more luxurious. And the Spring universe improves constantly - it seems with a new announcement every week (Spring Security 2.0 and SpringSource Application Platform being the latest big announcements).

The stack one can mobilize on Tomcat/SpringSource these days is just amazing. I love being able to assemble best of breed components and weave it all together seamlessly via Spring - there's nothing else quite like it that has so much breadth for doing that.

Of course my perspective is from point of view of using Spring to implement services to back web RIA - not server-side web frameworks generating HTML/JavaScript web pages.

Flash has had secrity

neatisca — Wed, 30 Apr 2008 10:21:47 -0400

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.

JavaFX Script, unlike

weiqigao — Wed, 30 Apr 2008 08:10:17 -0400

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.

These kind arguments all

rv49649 — Wed, 30 Apr 2008 04:34:42 -0400

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.

First off, asynchronous

neatisca — Tue, 29 Apr 2008 13:43:28 -0400

First off, asynchronous programming and threading pool have been supported in .Net for a while. If non-blocking, "fire and forget" kinda behavior is what you need then go for it. You follow a short routine and then hand it to the CLR run time which executes the underlying threads for your task. Using .Net asynchronous patterns is easy as A-B-C. I don't know about the Java world, but I'll be surprised if they don't have anything similar.

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.

This is also a competition

rv49649 — Tue, 29 Apr 2008 01:16:57 -0400

This is also a competition of programming models.

Multi-threaded programming via the .NET CLR and Java JVM APIs is not really the way to move forward in the web RIA space.

Implicit models of concurrency, ala async i/o and async messaging with worker thread pools (shades of Erlang) - when coupled with the language feature of closures - will be an easier model to program to (and easier to arrive at a correctly behaving applications in respect to concurrency).

This will especially be true of the swath of enterprise business applications that are being written to the web RIA approach.

There will continue to be some applications that will require the capabilities of the .NET CLR or Java JVM multi-threading APIs - but these apps will be edge cases. I've written a couple of such .NET WinForms apps that are heavily multi-threaded, interact with devices, ActiveX controls, and Windows APIs for very rigorous lock-down behavior. Yet they are disembodied from the business app side of things - one of them embeds a browser control so that the bulk of the business application that users interact with is delivered as a web app.

I believe it is better to segregate business applications from system programming style applications as the two are very different beast (even though they may be coupled so as to appear as one application entity to the user). This approach partitions the nature of the programming problem very appropriately and leads to a very flexible architecture - the biz app portion can be deployed to a wider range of context as it is web centric. Most importantly the biz app side is written by different programming expertise.

The .NET CLR of Silverlight and the JVM of JavaFX will muddy these two styles of program codes together - which is very inappropriate given the different kinds of skill sets these two domains of software development emphasize. Consequently it's clear Microsoft and Sun haven't given much forethought about this aspect of software. Yet the programming model really should be designed to be well suited to the contextual nature of the software.

By the way, Flex developers have been making most interesting strides in using Flex 3 to create programs that are deployed and run using the Google App Engine. This is one very exciting area of web RIA indeed!

rv49649 wrote:IOW, .NET and

neatisca — Mon, 28 Apr 2008 18:18:00 -0400

rv49649 wrote:

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

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.

rv49649 wrote:That's exactly

jas_ejb — Mon, 28 Apr 2008 12:59:13 -0400

rv49649 wrote:

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 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).

mrshanepaul wrote:The great

jas_ejb — Mon, 28 Apr 2008 12:55:03 -0400

mrshanepaul wrote:

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!!

Great line, and so true. :-)

Plus, the consumer JRE is

jas_ejb — Mon, 28 Apr 2008 12:54:10 -0400

Plus, the consumer JRE is just around the corner, where the base JRE will be a 3meg download, then it will download the other bits as it needs them.

rv49649 wrote:So Flash has a

mt79448 — Mon, 28 Apr 2008 07:02:22 -0400

rv49649 wrote:

So Flash has a runtime that downloads as less than 3 megabytes instead of amounting to 16 megabytes as does the JRE.

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.

Roger,I agree with all your

weiqigao — Sun, 27 Apr 2008 23:49:27 -0400

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.

jas_ejb wrote:I suspect

rv49649 — Sun, 27 Apr 2008 22:47:39 -0400

jas_ejb wrote:

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.

For systems programming of server-side application servers, .NET CLR and Java JVM multi-threading approach is what you want.

IOW, .NET and JVM multi-threading is actually going to be a significant liability for web RIA application development - not a positive asset.

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."

Adobe offers ColdFusion for

rv49649 — Sun, 27 Apr 2008 22:30:35 -0400

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):

Java 6 JRE
Tomcat 6 (supports HTTP listener using NIO and implements Comet Events protocol)
Spring 2.5
Spring Security (Acegi-based)
Spring JdbcTemplate and iBATIS (or could use Hiberanate or JPA)
BlazeDS 3.0
JDOM (for any server-side XML processing)
XStream (for any need of marshalling Java objects as XML format)
Spring OSGi (Equinox-based in our case)
ActiveMQ (for JMS messaging - messages published to a JMS topic are routed to Flex-based client subscribers via BlazeDS; Flex clients can in turn publish into JMS queues and topics)

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.

My point in detailing how

rv49649 — Sun, 27 Apr 2008 22:23:05 -0400

My point in detailing how far ahead Flex-based web RIA is relative to say, JavaFX, is the implication that JavaFX is purely Sun's "personal" corporate problem.

For you the Java developer...well, it really is not a problem for you as there is an attractive and viable solution here and now that integrates well with your Java server-side expertise. So from a business pragmatic point of view, you have a way to keep moving forward and build web applications (and desktop apps - i.e., AIR) that are state of the art.

Recalcitrant die-hards that must simply have a pure Java RIA solution will fall further behind in the market place because they put what are (relatively speaking) trivial concerns ahead of business reality concerns. (What is ironic is that I'm sure some of this same crowd bemoan Java's weakness in lacking certain language features - which some of these features will be ones that ActionScript3 happens to address, such as: properties, events, declarative data-binding, and closures.)

I dealt with a bit of that recalcitrant attitude in my Flex-based projects too. Yet when folks got immersed in working with Flex-RIA, all their preconceived prejudices faded away. It helps that Flex is a technically astute solution. :-)