Is Java losing Ground to Flex?

by Moxie Zhang on Nov 13, 2008 |

As rich Internet application (RIA) technologies mature and become more widely visible to developers, inevitably they will cross with established technologies, like Java. A recent blog post from the game development company Sharendipitous Moments, entitled “We’re Moving to Flash. Here’s Why,” created discussion on whether Java is losing ground to RIA technologies, such as Flex.

The post starts by recognizing that Java is still a superior technology:

The Java language is way better than ActionScript and Java compilers are much more advanced. There are also more possibilities with Java. Moreover, even though Flex Builder is built on Eclipse, the Eclipse development environment for Java is years ahead. I say that with no bias, having just finished porting about 800 classes and nearly 60,000 lines of Java code to ActionScript.

The major reason for Sharendipitous Moments’ switch to Flash-based development (Flex) is the Java brand. In this respect, the post notes:

Java’s brand is failing. JavaFX has long been touted as the solution to Java’s woes, but it has been too long in getting released. In the meantime, Flash has continued to dominate. Silverlight has come on as a competitor, but it will be years before it has the same kind of market penetration as Flash.

According the post, the result of the brand failure is, “If you see the Java applet loading, you click every visible link that you can to get off the page.”

Many developers can’t agree with Sharendipitous Moments’ decision. As one developer complained:

None uses Flex for anything serious out there. But, the blog writers disagree for some reason. They all talk about how Java is bad, and Flash is really awesome. JavaScript JIT-capable browsers are hitting the market. Are you aware of that? It is not Java that Flash should be targeting but completely browser-based applications. At the same time, Java will always be there living either at the server or the client.

Nevertheless, some developers shared experience similar to those reported by Sharendipitous Moments. For example, Frank Sommers, a Senior Editor with Artima Developer, comments: “I also just finished migrating a large Swing app to Flex, and my experience has been very positive. The only thing I really miss is a good IDE, such as IntelliJ. Flex Builder 3 has a long way to go before it gives you similar productivity features.”

Blogger Ken Russell from Sun joined in as well:

It’s disappointing to hear that Sharendipity (one of the featured JOGL apps) is moving to Flash. We just completed a major rewrite of the Java Plug-In in Java SE 6 Update 10, which makes Java applet deployments more reliable, powerful and portable. 6u10 is available for Linux, Solaris and Windows now, and we at Sun are actively collaborating with Apple to bring it to the Mac. It is the first in a series of steps being taken to revitalize client development on the Java platform.

Martin Wildam, a software development consultant, takes a more moderate view:

I think your decision cannot be generalized. From the view of the default user, I can imagine that you are right that they might click away earlier when they see Java starting. However, I also remember Flash things loading for a longer time. Users might not be aware of that because different animated stuff is presented to them. If they always saw the same Flex-loading-logo, they would also be likely to click away.

Java World observed:

Meanwhile, Java Lobby has a helpful article that will help Java developers jump ship to Adobe's RIA platform. If that's not bad enough for poor JavaFX, Frank Sommers over at Artima Developer feels that the still infant RIA language is stealing valuable development time from Swing.

The author of the post, Dale Beermann, summarized the discussion, commenting,” I love this dialog. This is a huge decision, and I’m eager to hear what everyone has to say. Keep it coming.”

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Ported a ball of string? by Greg Matthews

Hmmm..this article might need clarifying to say "Java on the UI is failing".

Depending on the type of apps you write, the UI should be a thin veneer, with most of the code being in services, which for my 2c should be in something like Java where heavy lifting can be done.

If the /entire/ app is in Flex, I can't imagine that it does anything enterprisey? Are we talking little calculator Flex apps or poorly architected apps here?

Java on the Back-end by James Ward

I really don't think that Java is losing any ground to Flex since the two technologies work best together. In fact I believe that Sharendipity is still using Java on their back-end. Use the tool that works best for the job. Flex is great for client-side RIAs. Java is great for back-end servers. A perfect match!

-James (Adobe)

IntelliJ's Flex support by Carl Byström

Being both a Java and Flex developer, I've been longing for Flex support in IntelliJ for a long time.
IntelliJ 7 had support for Flex but unfortunately that wasn't production ready, at least not for me.
However, version 8 was just released here the other week and I've already moved all production coding over to IntelliJ from Flex Builder. Goes without saying that I'm more than pleased with the migration.

If I sound like a total JetBrains fanboy, it's probably because I am one :)

Flex can do this ? by Andrei Dore

Flex can do this ?

You must have the newest java jre installed ( 1.6.0_10)

Re: Java on the Back-end by Mark N

I wouldn't say it is a perfect match. Of the things available in production today ... it is the best match possible. Java on the client AND the server would be the perfect match. That is why some of us are holding out hope for JavaFX.

Re: Flex can do this ? by Dave Nicolette

Very cool applet, but I'm not sure the example makes a strong case for applets over flex for rich UIs in the browser. Reasons: (a) The applet took two minutes to load, and (b) you don't need jre 1.6.0_10 to run a flash object.

I agree with those who see Java working best on the back end and something lighter-weight working best on the client.

Re: Ported a ball of string? by Michael Bushe

Depending on the type of apps you write, the UI should be a thin veneer, with most of the code being in services

Apps with "thin veneers" for UIs are only loved by the server-side engineers that wrote them, not real users. Nice UIs are harder to write than mundane services.

Re: Flex can do this ? by Neil Bartlett

So you're asking if Flex can hang my browser for two minutes, throw up four incomprehensible security warnings about certificates, and then just display a dead grey rectangle?

Hmm, no I can't say I've ever seen Flex do that.

Maybe my JRE isn't up-to-date enough, I only have the very latest available for Mac OS.

Re: Flex can do this ? by Mark N

So you're asking if Flex can hang my browser for two minutes,

I've had Flash do that.

and then just display a dead grey rectangle?

I've had Flash do that (well no rectangle to tell me something should be there)

throw up four incomprehensible security warnings about certificates


For applets that are equivalent to Flex apps - there should be no warnings. If there are, that is the fault of the developer.

Re: Ported a ball of string? by Greg Matthews

Depending on the type of apps you write, the UI should be a thin veneer, with most of the code being in services

Apps with "thin veneers" for UIs are only loved by the server-side engineers that wrote them, not real users. Nice UIs are harder to write than mundane services.

Hey, Flex is great, but doesn't mean all logic goes into the UI. For any non-trivial enterprise app, there is very likely going to be other consumers of a service, other than the Flex app. Getting the services working robustly, unit tested, etc, and then wiring them into your rich or non-rich app (whatever) is the way to go.

keep it DRY == Java services by Roger Voss

We're tooling up a large enterprise app using Flex for client and Java for middle-tier services. We don't want to have redundant code in our flex client modules (even if linked in as sharable swc libraries - makes fatter and larger downloads). So we'll put code that has relevancy to multiple client modules into Java services. Keep things DRY.

Flex could be done on top of something like Adobe's Live Cycle Data Services. But that promotes the tendency to do practically all the development in Flex client code. We're rejecting that approach. So for us, Java will continue to play a vital role.

Re: Java on the Back-end by Roger Voss

I like Java very much but darn, for GUI, the Flex SDK and MXML/ActionScript are very adept. I like programming GUI better in MXML/AS3 better than Java and Swing.

MXML makes for a nice declarative way to frame out the core of a visual surface. Is more concise and clear than procedural coding of that. AS3 properties, events, and data binding are nice relative to Java's poor man's JavaBean conventions. AS3 closures are nicer to program async and event-driven code than Java's anonymous inner classes. The fact that all Flex i/o operations can be done in async manner with closures for handling results and faults, is an easier programming model than using Java threading to accomplish the same.

So no, Flex client-side + Java server-side is indeed superior relative to Java client-side + Java server-side.

Re: Flex can do this ? by Michael Armishaw

Clicked on it - no plug-in. took 3 minutes to install. Clicked on it again and got an error. Class not found exception. Impressive!

Re: Flex can do this ? by Gabriel Molina

Let's be fair, in order to run an applet or a flex app, you need to install aditional stuff: jre or flash player. Both can hang your browser (thanks Adobe for your support on 64-bits) and both can throw "incomprehensible" security warnings. I think flex is a great solution 'cause is lighter than applets, but for this reason is less powerful.

Re: Flex can do this ? by Sarath Chandra P

The Replies (and the article itself) are not really measuring up.

Flex is a production ready app. JavaFX is not even in sights. Flex's disadvantage is it has to use ActionScript (and a combination with MXML) So its a different development curve. Need a new skill set for it.

JavaFX is YET to come. When it is in, You will be able to ask your java developers on day one to start working on it. Little or minimal learning curve. The big disadvantage is sun's inability to deliver it in the right time. Java's and J2EE's success story remains much credited to the timing. It was Microsoft playing the catchup then, and Now its sun.

I am not a proponent of JavaFX. I dont develop RIA UI. But I just think this comparison is not apt.

Re: Flex can do this ? by Steven Libonati

I'm not sure I'd really call it a development curve and that it would require a new skill set? I think if you are an experienced Java developer or any OO language developer for that matter, picking up Actionscript would be fairly easy. I think most in the thread have it right. They are complimentary technologies and it happens that Flex and Java are most suited together. Throw in Spring on the middle tier and your exposing your Spring managed services to an RIA client! Using Remote Objects and AMF, your AS objects are mirrors of your Java objects.

Re: Flex can do this ? by Roger Voss

I agree, Flex + Java + Spring make a great combination. We insert BlazeDS in there as well for AMF-based remoting and messaging. Nice thing is that BlazeDS can be configured to use Spring as its factory mechanism. So a bean that is a handler for a BlazeDS-based remoting call can be a Spring bean where it's configuration requirement is placed in the applicationContext.xml file.

ActionScript and Java have a lot of similarity. It doesn't take long at all for Java developers to pick up MXML and ActionScript. Does take more time, though, to learn the Flex SDK and how to do things proficiently with it. Or learn one of the MVC frameworks used with Flex, like Cairngorm, Mate, or PureMVC.

The one comment in the article about Java being way better than ActionScript is very much misplaced. AS3 has a lot of similarity to Java, and like Java has static typing that is checked at compile time (though can still use dynamic objects ala old-style JavaScript if situation warrants). Additionally AS3 has true properties support, events, databinding (declarative-style form MXML), and closures. These particular features make GUI programming in MXML/AS3 a lot better from a programmer's point of view than doing same in Java. (I've done GWT and Swing.) The code is clear and more straightforward.

JavaFX not really started yet by Hanno P

First I think that Java will never lose ground on the server side to something like Flex. I think Adobe feels quite comfortable with having Java as their back end for Flex.

I do not understand how some people declare JavaFX dead already before it even started.
Flash is out there for quite a long time now without having a real competitor besides AJAX. So of course other/new technologies have to catch up. But who says that they cannot do that?
Right now AJAX is still very popular on the RIA side and will be for quite some time I think, so there will be still some time until Flex, JavaFX or Silverlight take over.

Silverlight is also very new, the version number "2" is confusing, because this version is actually the first that is fully featured and usable. Besides that I don't see many projects/applications running on Silverlight, so it has quite the same distribution level as JavaFX has.

I think JavaFX looks very promising and is a big step forward to client side Java.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

18 Discuss

Educational Content

General Feedback
Editorial and all content copyright © 2006-2013 C4Media Inc. hosted at Contegix, the best ISP we've ever worked with.
Privacy policy