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?
- Login or register to post comments
- 3960 reads
- Email this Article
- 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
Konstantin Chikarev replied on Thu, 2008/04/24 - 9:07am
Jesper Nordenberg replied on Thu, 2008/04/24 - 10:46am
Hype and buzz words...
JavaFX is just a marketing thing, the technical innovation is null. Scala + Web start is a much more powerful combination for creating "rich Internet applications", whatever that means...
Azrul Hasni replied on Thu, 2008/04/24 - 11:28am
Here's my 2 cents on JavaFX
http://ejn3.blogspot.com/2008/04/to-mr-jonathan-schwartz-please-make.html
Weiqi Gao replied on Thu, 2008/04/24 - 1:03pm
Considering that Adobe Air and Microsoft Silverlight were both released less than a year ago, I don't think JavaFX is too late. The functionality of JavaFX is competitive with the other two products, so it is not too little either.
The Java root of JavaFX, the availability of it on the mobile phones, and the open source implementation of JavaFX are three huge advantages that are not matched by the other two players.
If this RIA thing is going to take off, which at this moment is not certain, I think there are rooms for all three players, each with their own developers community and usage scenarios. Microsoft, Adobe, and Sun have betted that RIA will take off. And we'll see if that pans out within the next eighteen months to two years. At that time, nobody would remember that JavaFX was released a few months later than Adobe AIR.
Casper Bang replied on Thu, 2008/04/24 - 1:31pm
Following various other projects, i.e. JSR-296, it's plain to see that JavaFX is eating up resources from all over caused by Sun's desire to armwrestling Adobe. While I am sure we will see some more marketing demo's as is the habit at JavaOne, it's too little too late. Enough with the vapourware - Sun, you've had your chance with Applets but chose not to follow through. Flex is soon out in 3'rd generation and Silverlight in the 2'nd, meanwhile Sun's delivery mechanism is still only in beta and a much larger download than both Flex and Silverlight.
Rather than just focusing on a new DSL like JavaFX and the all-devouring topic of closures, it would be nice if Java the platform was modernized and strenghtened a bit instead, legacy issues dealth with and new groundbreaking technologies brought in like we saw in the 90's. That would create some passion again on my part.
Roger Voss replied on Fri, 2008/04/25 - 2:12am
Flex 2.0 was the milestone event where Adobe Flex RIA really took off in earnest. Flex 2.0 shipped to the public Jan. 2007. Prior to that, though, it was well seeded as a beta release from August 2006 onward, and to me, Flex was the most impressive thing I saw at JavaOne 2006.
Flex 3.0 and AIR shipped Feb. 2008.
Adobe is busy working on Flex 4.0 - yes the fourth iteration of Flex RIA technology - and it is Flex which truly puts RIA into the Flash Player runtime.
Silverlight, on the otherhand, has only released final bits for 1.0 - which is nothing but a media player. It is not at all a competitor to Flex RIA.
Silverlight 2.0 - which will finally add some "off-the-shelf" form controls - will be the first iteration that will have sufficient features to be classified as a RIA platform. However, Silverlight 2.0 still remains just a beta release. Its final bits are not expected until around late summer or fall.
By that time frame, Adobe may very well have shipped Flex 4.0. IOW, Adobe will be on its 4th generational iteration of RIA, Microsoft on its 1st, and Sun trailing behind also attempting to get final bits out for a first iteration of JavaFX.
At my company I'm leading development on a 2nd Flex-based application project. The first Flex-based app one of my teams delivered, has just finished a v1.1 revv, and they're now starting on v1.2 of that Flex-based product. Lots of companies have already done their first round of Flex applications and have gotten them into the hands of customers. Customers love the Flex style of RIA UI - particularly in contrast to the old school web UI of conventional HTML/JavaScript apps. There's no doubt about it - Flex RIA is superb for business apps.
So especially in the enterprise space the RIA train has already left the station and the strategic enterprise development choice was made. It's called the window of oppurtunity or WOO. Adobe Flex 2.0/3.0/AIR, hitting the RIA sweet spot right on with near perfect alignment, also enjoyed great timing with respect to the WOO factor.
Silverlight does have one thing going for it, though - die hard .NET development shops that won't touch anything unless it comes out of Redmond. (Flex + .NET-based SOA can actually be a great combo for them to consider, though, as then they'd be able to ship RIA apps to a runtime player that has about 95% penetration of browsers accessing the Internet.)
Same with JavaFX - there is a cadre out there in the Java community that will hold out for a Java-based RIA solution. This despite the fact that Flex and Java make for a great marriage - with Flex being a very easy and natural uptake for Java developers. Java developers feel right at home in ActionScript3 and immediately appreciate the advantages that language has over Java in several respects. Yet it remains on balance a very simple language.
Folks that have already adopted Flex strategically may very well be doing their 3rd generational project efforts on Flex/AIR by the time Silverlight and JavaFX reach final release bits status. That's how far behind the curve those other RIA platform contenders are.
Guido Amabili replied on Fri, 2008/04/25 - 4:59am
Well, I don't think JavaFX is too late, since the RIA market is so small.
My platform for enterprise development is AJAX + WS + JEE.
If I have to develop a thick client, than it is Swing + Webstart or one of the other deployment technology available.
For a website, well the targets are the Browsers and I use such free and open standards like HTML, CSS, XML,XSL......................................................
I feel the most productive with these technologies, and I know how to tackle issues like Accessibility, Security,..........
Regards, Guido
Roger Voss replied on Fri, 2008/04/25 - 10:25am
in response to: guidolx
neatisca replied on Fri, 2008/04/25 - 9:56pm
I'm sure Flex can blow the pants off these DHTML + AJAX + CSS web apps. But us .Net developers, "die-hard" or not, are not going to pick it over SilverLight. It's pretty much true that we don't touch anything unless it's from M$, and there are good reasons behind it. The feature set of SilverLight 2 shows it can do what Flex is doing now albeit w/ some beta crash. A brief look-at Flex on the other hand reveals ActionScript lacks of overloaded methods, LINQ, generics and Multithreading. The first 3 maybe optional, but Flex won't really be a serious RIA platform if it doesn't have multithreading. W/ those features missing, Flex is not that much ahead of SilverLight. Java folks would probably point out the same issues.
W/ SilverLight, there's no need to learn a new language. A big plus for both developers and managers. Imagine you are hiring a team on a Flex project, you have to find guys w/ two skill sets: ActionScript for the front end and Java/.Net for the backend. W/ SilverLight, you just need one. Therefore we .Net developers are gladly locked in by SilverLight.
Also, programming language/platform is M$' ace game and they have no problem catching up. When C#/.Net came out in 2001, they were trailing the overwhelmingly popular Java by 6 years. People laughed them off as Java wannabies. What is happening now? .Net goes neck to neck w/ J2EE evenly. If they could handle Java being that much ahead, they can handle Flex just fine.
JeffS replied on Sat, 2008/04/26 - 10:32am
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.
Roger Voss replied on Sun, 2008/04/27 - 10: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.
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 - 9: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 - 10: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 - 9: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....?!
Roger Voss replied on Sun, 2008/04/27 - 10:23pm
in response to: mrshanepaul
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. :-)
Weiqi Gao replied on Sun, 2008/04/27 - 11: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 - 7:02am
in response to: rv49649
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 - 12:54pm
JeffS replied on Mon, 2008/04/28 - 12:55pm
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!!
Great line, and so true. :-)
JeffS replied on Mon, 2008/04/28 - 12:59pm
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.
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 - 6: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
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.
Roger Voss replied on Tue, 2008/04/29 - 1:16am
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!
neatisca replied on Tue, 2008/04/29 - 1: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 - 4: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 - 8: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 - 10: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.
Roger Voss replied on Wed, 2008/04/30 - 10:29pm
in response to: neatisca
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.