Dr. Gosling says the grapes are sour!

by Shashank Tiwari

In a recent interview Dr. Gosling said -
"If you look at something like Flash, when you get to the much more advanced stuff -- with richer interfaces, more complex network protocols, more complex APIs -- it really falls short."
Source : Redmond Developer News

While, I would agree with Dr. Gosling, that the Flash VM, the ActionScript library and the Flex framework is not a be-all and end-all RIA solution (remember that its incarnation as a application developer's tool -- as opposed to a designer's easel -- is fairly recent and it is continuously and rapidly evolving as we speak!), I have a feeling Dr. Gosling is actually saying that the grapes are sour ! (For those who may not be familiar with the fable of the The Fox and the Grapes read on and you will quickly see the connection.).

At this time in its current form and shape Flex is a great option. Further, far from being competitive, at Saven Technologies, we have experienced that Java and Flex are complementary and can help build rich interfaces fairly effectively. Let me explain some more of this, but before that let me dissect Dr. Gosling's comments and set the context.

Dr. Gosling has specifically pointed out that the shortcomings are related to support for networking protocols and complex APIs. My reply -- TCP and UDP are two popular transport level protocols. Flash supports TCP. It does not support UDP. At the application level Flash supports HTTP and HTTPS. It supports AMF, which is a SOAP like but more efficient message format, and RTMP, which helps stream audio, video and data across the Internet. It does not support many application level protocols including SMTP, POP3, RTCP and many more. With the protocols in Flash repertoire one can build most consumer applications that utilize HTTP, Web Services and RESTful constructs.

One of our financial services clients was not satisfied with this. Not only did they want remote procedure calls, they desired real time data push and secure connectivity. With the help of LifeCycle Data Services, a server side integration technology that runs without a fuss in any Java application server, and the protocols mentioned above (AMF and RTMP), we could easily achieve what our clients desired. LifeCycle Data Services has open source cousins -- BlazeDS, GraniteDS and more.

So while Dr. Gosling is right that Flash does not support as many protocols as Java does and he is also right that it does not have direct support for complex APIs, let's say for messaging systems or database connectivity, the question is that does flash (with its Flex framework) really fall short because of the lack of these. Not really, on the contrary it piggyback on Java and PHP and others for such extensions. We are primarily Java experts who graduated to using Flex as the RIA and we see no trouble in leveraging the Java infrastructure that is so rich and robust. In the application that I was talking about earlier, that required real time updates, we used JMS for subscribing to the market data feed publications. Flex messaging and JMS worked well together and it was just fine.

Finally, Java Applets has support for many networking protocols and complex APIs, then why is it falling short of expectations? Weren't there other things, including the well known JRE version mismatches that brought it down? Why is Sun creating JavaFX if the most critical ingredients -- at least the way its worded it makes me believe that these are so -- are already brewed in?

I feel very disappointed when a person I deeply respect and revere needs to make such comments. Java as a language and platform is very comprehensive, user friendly and productive (despite all the noise from the Rubyists) and works in harmony with many other technologies, including Flex. If JavaFX and the Consumer JRE deliver the promise I am happy to adopt it, as I have adopted Applets, Swing and the Java web application technologies so far.


Mark Fortner
2008-01-14 12:07:06
Let's say that a year from now, we have a situation where there are two versions of the Flash plugin available. The newer version has support for some new features that you want to use. But your installed base hasn't updated to the latest version of Flash. Isn't this the same situation that applets were in many years ago? Does Flash have the equivalent of webstart to insure that the Flash-app gracefully degrades, or that the appropriate version of the Flash-app runs?
Shashank Tiwari
2008-01-14 13:43:56
The current Flash player is version 9 and so far version upgrade and reconciliation has been managed in a seamless and elegant manner. The Flash Player Detection Kit allows developers to effectively manage upgrade of existing flash player versions or installation of new ones, as required.

Although, its now almost resolved the issues due to JRE version mismatches in Applets were the most pesky and painful ever.

2008-01-14 16:22:06
The big advantage Flash has over Java is that the player download/install is tiny compared to the JRE plugin. You can prompt the user to download the required player version if they don't have it, and the whole process will take less than a minute. Try that with the JRE with its huge download and install wizards, etc.
2008-01-15 00:02:59
About 4-years ago my organisation implemented a document imaging solution based on Flash and ColdFusion running under WebLogic. A lot of the back-end code is written in ColdFusion and Java but the front-end is all Flash. Unfortunately, the front-end was developed in Flash MX prior to the advent of Flex and porting our code to Flex (according to Adobe) would be very difficult so we're going to be stuck with the designer's easel for some time to come.

As far as I am concerned, the only issue that we have with Flash at the moment is that its connection to the back-end times-out after 30-seconds so the results of document queries that take longer than this to run are never returned.

2008-01-15 07:26:33
there are a lot of financial services companies using applets internally successfully.

fidelity uses applets for its charting externally + successfully

LifeCycleDataServices costs $$$$$$$$$ and you can push for free w/out flex.

there are also a lot of financial services companies who build their UI in .net and backend in java. this will certainly become an option when silverlight goes mainstream as opposed to flex

Shashank Tiwari
2008-01-15 09:51:41

The Consumer JRE promises to alleviate the pains and problems associated with download size, install time, startup and JRE detection. Chet Hasse's article on Consumer JRE beautifully and tersely explains whats coming.


Shashank Tiwari
2008-01-15 10:07:15

You are right that many financial service companies continue to use Applets and Desktop Swing applications. However, that does not undermine the problems associated with distributing such applications. You may want to read the article on Consumer JRE that I mentioned in the earlier reply to see how Sun is addressing these issues now.

Also, you are right LifeCycle Data Services is a paid piece of software and often thought as being expensive (although that may not always be accurate!). Adobe recently launched BlazeDS as an open source data services option that facilitates remoting and messaging, which is what you need most of the time. Not to forget options like GraniteDS have been there for a while as well!

Your third comment about using .Net with Java back-ends is interesting. I am familiar with similar architectures in a few large investment banking and trading outfits. Such configurations often need extra deployment infrastructures and resources which tend to bloat the total cost of ownership. Having said that it cannot be denied that with or without Java, Microsoft Silverlight is emerging as a viable RIA option.

Karsten Silz
2008-01-15 16:35:14
I agree with the author that as a rather loosely coupled client, Flex / JavaFX / Silverlight doesn't typically need more than HTTP / HTTPS to communicate with the business / data / back-end layer. AMF is more efficient for Flex only, TCP is only for special cases (if you get through the firewall) and RTMP is good for media streaming. I'm rather sure that Mr. Gosling knows that as well, but he has to hype something that hasn't been fully released yet (JavaFX) vs a rather mature technology (Flex). :-)
2008-01-15 17:46:52
It's ironic that he makes such comments, given that JavaFX is still somewhat at the prototype stage. There's no satisfactory delivery mechanism and dependencies are huge (rt.jar and javafx.jar). Silverlight seems interesting (in that you can use any language on a 4MB runtime), Flex is impressive for all the known reasons but I seriously doubt it's worth it for Sun to investing in another layer. They should try to fix the issues with the existing ones first - and no I don't mean change NASDAQ ticker.
Jin Chun
2008-01-15 20:14:26
no offense, but we have stripped out Flex on the server where I am, and are almost finished getting rid of it all together. Once you go beyond the internal firewalls, the protocol support starts to break down (for example, try pushing RTMP and LDS across a set of authenticating proxies, it doesn't work, unless they just fixed it).

2008-01-16 05:27:49

Sorry if I sound a bit harsh but you're dead wrong to promote GraniteDS.

At the time of this writing it clearly states on their website that it's for "non critical production environment".

It irks me when people promote a technology as opposed to good sound business decisions.

I haven't looked in to BlazeDS; call me a cynical veteran but I'll wait a little while...I wouldn't stake my reputation / position on building on top of a very new technology.

I've been working in investment banks for all my career and almost exclusively with java backend, swing or c# front ends. no issues with deployment. if you have issues, I'm sorry to say that it might be due to the quality of your team. You get what you pay for.

I'm not sure where you are getting the need for a whole infrastruture + total cost of ownership from for occassionally clearing the web start cache, but at our planning stages the total cost of ownership w/ LifeCycleDS on a quad core machine + FlexBuilder's was far more expensive than c# or java front end.

Shashank Tiwari
2008-01-16 08:10:04
Its absolutely fair to honestly put forth your opinion and my apologies if my viewpoint angered you. Let me clarify though that at any point in my blog I am neither trying to promote GraniteDS nor BlazeDS. I am just stating them as options, which they are!

Now, as far as new technology goes - All of Flex and RIA (including JavaFX, Consumer JRE, Silverlight and more) are new ! Like you most people in the enterprise are shy to adopt new technology and rightly so because often the downside due to unknown bugs could turn out to be expensive. On the contrary though all types of technology is evolving at a rapid pace for the last few years and enterprises could easily lose out on the advantage if they wait too long.

The issues I mentioned are real and have existed in the Applet world for over as long as the Applets have existed. Unfortunately, the issue wasn't with people this time :) As far as the costs go, remember that development costs, ongoing maintenance and resource requirements with simultaneous use of Java and C# is high. Its not about the Webstart cache.

Hope that helps! In any case, there is no single story that uniquely defines all experiences and I am happy that java backend, swing and C# have worked just fine for you. These are all good and viable technologies as far as they meet your requirements!

Michael Galpin
2008-01-16 15:37:01
Actually using REST with Flash is not as trivial as it might seem at first. The Flash player does not provide access to the HTTP headers, which is necessary when using REST.
2008-01-16 16:08:39

You didn't really anger me, it was more that I wanted to clarify GraniteDS status.

I wouldn't call Flex new as it's on major version 2.x and has been around for years(2004)...however it's perceived as new b/c it's really just recently that it hit mainstream(same goes for Ruby) Don't get me wrong, I built a proof of concept leveraging the existing backend and there are certainly some things to like. However I did draw up a plan submitted to senior management w/ regards to switching to Flex as the UI and it was no cheaper than Swing, C#

Total cost of ownership also includes the cost to formally retrain a development team, buy server + development licenses and on the job learning which will certainly slowdown development time. Another thing that adds to costs are if you have a good strong component library already written in Swing, C# etc converting them to Flex is very very expensive. Flex developers are no cheaper than any other developer esp w/ supply being low -- resource cost doesn't differ from having a good developer in any other popular language. And outsourcing this to a firm already strong in Flex is certainly an option, however costs will certainly arise in teaching them the business(especially in complex financial applications across different asset classes)

Maintenance costs are a gray area because though they are certainly more expensive than initial development, to get a good metric comparing technologies, you need to separate out what is maintenance from a purely technological point of view versus business induced changes, which would occur regardless of platform chosen. In a well designed delivered system, most ongoing maintenance costs are of a business nature. A poorly designed system will incur high technical maintenance costs regardless of platform.

Perhaps applets are the appropriate technology to compare against Flex as the both run in the browser, but applets can be done very well too -- Fidelity uses applets for charting in their online trading and they've done it very well - fast, responsive, and the look and feel blends right in to their website.

That being said, I'm happy that both Flex and Silverlight have made it to the scene; competition is good and just brings out better stuff + solutions down the road.

Shashank Tiwari
2008-01-17 17:00:04
You are right HTTP/GET header manipulation is not trivial with Flash. There is a workaround by using sockets. You may want to read Abdul Qabiz's blog on HTTP Authentication to understand how he managed these requirements (in a different context).