My Observations
["RIA with Adobe Flex 2 and Java" by Yakov Fain, Victor Rasputnis, and Anatole Tartakovsky Vol. 11, issue 5]

I have been working both with Java Swing and ActionScript while creating a GUI. Here are my observations that defy your statements in the article.

1.  "Imagine the amount of Java code you'd need to write to achieve the same functionality." There are a number of Java XUL implementations and Swixml is one of my favorites.

2.  "...but we wouldn't have to worry about routing all events to the event-dispatch queue." In Java, you use listeners and handler functions to attach to the GUI events. Events are routed automatically. Creating custom events in ActionScript would take just as much effort as in Java (or probably less, since it has Observer,Observable and other utility classes in the rt library, unlike Flash).

Now the drawbacks of using Flash (components v.2) over Java:

1.  Flash components are badly written; there are many undocumented bugs that you would never overcome, e.g., try adding a combobox to an accordion pane, or a menu inside of a scrollpane. The most awful truth about Flash components is that they are badly integrated with one another and putting them inside one another will most likely result in something quite unpredictable (only frozen layers from a component can be seen; the focus frame cannot be set; dropdown layers are displayed underneath another nearby components, etc.)

2.  Flash components are closed source. Even if you care to dig into the truth, you wouldn't risk changing anything because the bug is in the layered structure of the Flash drawing and there are some constraints on using the depths of those layers.

3.  There are no skins for different components, and it's unlikely that Adobe will come up with something unbuggy in the next release, since their main interest is increasing the feature set and popularizing some visual benefits, but it's hell for programmers. (Some 4+ releases in my history have proven that at least to me.).

4.  Flash has no threads, no thread management. If you start some calculation or even a simple data manipulation or object creation during some visualization process, you get a freezer.

All the rest about the small size, video/audio, Web integration, cross-platformedness is true, but I wouldn't use Flash in a project with complex GUI.

-Vitaly Sazanovich

Vitaly,
Thank you for your feedback. Let me start with one "platform" statement: Flex is the application server solution with a service-oriented client layer built on top of the Flash Player.

Now, I'll jump to the point where you started agreeing with us and from there will walk through the list of concerns all the way back.

4.  "Flash has no threads, no thread management."
I find this rather hard to justify as it is.

Multithreading capabilities are implemented in browsers as well as in the Flash Player. You may question, however, the level at which these capabilities are available to a programmer. After all, the beauty of XMLHTTPRequest is that it is asynchronous, isn't it? Otherwise we'd be saying JAX instead of AJAX :). Similarly, the same asynchrony has been available with Flash Remoting since 2002 or 2003, if I am not mistaken.

Let's take your use case - "some calculation." Must be something CPU worthy, I guess. The question is where does it belong in the distributed system, regardless of the Swing/Flash debate. Perhaps on the server, closer to data sources? Then, using the remoting capability of Flex/Flash, I would suggest a POJO running not only in a separate thread, but also on a separate machine, across the wire!

Now, just out of curiosity, let's try to play without the server, with Flash alone. Here is another take: can you have another "servant" application run by the Flash Player within the same hosting HTML page? Can you interop via the LocalConnection object to invoke methods, pass parameters - all with complete marshalling of complex data types to native objects?

Wouldn't it be happening in a different thread?

Perhaps we can come to a more accurate statement: there is no pre-emptive multithreading within a single Flash VM. This might indeed be an issue if we had to take distributed computing out of the picture.

But we don't have to, do we?

3.  "There are no skins for different components..."
This one is simpler. If you are, in fact, talking about Flex, which has a totally different code base than Flash controls, the statement is outright ungrounded. Flex controls support pretty advanced skinning, although my fascination with the subject went south after I skinned a couple of controls.

But then here's another part: "...Adobe...main interest is in popularizing visual effects..."

Well, this is one very popular illusion, I might say. How about this answer: Adobe Flex offers developers a JMS adapter that enables them to create a producer or consumer with one line of XML code? How _visual_ is that?

2.  "Flash components are closed source..."
I have a secret to tell. Flex comes with full sources. Look at them, step them through, do whatever you please. Just don't tell Adobe I told you :). Seriously, are we sure we are talking about the same products here?

Our article was about Flex.

1.  "Flash components are badly written..."
If indeed we are both talking about Flex, I find their components extremely well done. Not that I doubt for a split second that you can find a handful of cracks in each of them. But, being an expert, you naturally see how to avoid a problem - in another split second, don't you?

Also, now that you have the full source code of the controls (you do, I kid you not), what stops you from overriding any given method and creating your own Accordion or whatever? The Flex community and Flex engineers are very friendly people who will gladly accept and appreciate any good ideas you might want to offer.