James Gosling on Adobe Flash / Flex / AIR

When James Gosling comments on Flex/Flash:

Answer: If you look at something like Flash, when you get to the much more advanced stuff -- richer interfaces, more complex network protocols, more complex APIs -- it really falls short. We've had a platform for years that can build rich Internet applications that are extremely sophisticated.

Yeah, I don't know. Seeing things like this don't make me feel very comforatable about flex. (or air, or whatever you want to call it)

ducktyper.com/2007/12/27/flush

I really hope that JavaFX closes the gap between Flex/AIR and Java. I consider myself a Java developer, but have had to learn Flex/AIR because of the deployment and swing shortfalls with Java. I really hope that JavaFX and the consumer JRE fix these issues, but I'm going to wait till I see it to believe it. I think very highly of Gosling, and it does look like JavaFX has potential. That said I'm going to hold my excitement until I have download a finished product that works as advertised.

Flex/AIR has a lot of polish and generally work as advertised. I would go so far as to say that Flex is an underrated product right now. I have been pleasantly surprised by its component model. Out of the box there is a wide array of components, they are easy to use, and provide a very reasonable amount of flexibility.

In response to ducktyper.com/2007/12/27/flush: Yes there is a bug, or in this case a design issue. As if we have not seen similar things in Java over the years. These things get fixed.

It is strange to me to question the completeness of the Flash / Flex platform when JavaFX is not shipping (isn’t that slightly more incomplete?). Also, I have not heard a cry for additional network protocols in Flash. Is this really an issue for those building RIA’s?

Our issue hasn't really been, can you build interesting rich Internet applications? But that it's difficult.

I'm with Matt. I too have experienced a few hiccups with Flex/Air. This stuff happens in every language/platform and does get addressed.

Our Flex app used Flex HttpService and Flex XmlSocket for I/O and has had no issues with those. We use XmlSocket to perform server-side push.

Flex also has a Flex Socket class for doing arbitrary socket based programming, including binary data protocols.

In conjunction to the recently open sourced BlazeDS server-side messaging system, Flex supports the Comet pattern (which enables pushing events/messages to the client in a manner compatible to HTTP and port 80/443 firewall restrictions).

BlazeDS beta is available pre-integrated from Adobe with Tomcat 6. Tomcat 6 has support for a Java NIO-based HTTP listener and the Comet Events asynchronous programming model for Java servlets. This should enable a rather high scalability of individual servers using Comet-based messaging in conjunction to Flex clients.

I wonder if Mr. Gosling may have been referring to UDP?

There's also an ActionScript STOMP client so that any Flash/Flex application can use a message broker like Apache ActiveMQ to provide reliable messaging inside the application.

James
Iona
Open Source Integration

I could imagine "two kinds of network protocols missing in Flash" that Mr. Gosling refers to:
- UDP on the low level, and
- SMTP / POP / IMAP / JMS / JMX etc on the high level.

Now if you build a consumer application with Flash / Flex, you really can only count on HTTP and HTTPS being available and not being blocked, so those protocols are not really missed there. For an application inside a company you could use these protocols, but I think the trend here goes to web service / REST / XML over HTTP protocols for loose coupling between the client and the server which are all possible in Flash Player, so the missing protocols may not be a huge issue there, either.

The one thing that people could really complain about is lack of UDP for efficient audio / video streaming (as brought up in a comment to the response by Abobe mentioned in the article). The Adobe fellow said there that UDP often gets blocked which is why Flash uses TCP, and one can't argue that Flash is the king of video streaming on the Internet now. Of course, you could try UDP and fall back to TCP if fails (as suggested in another comment there).

>> I think we have a much broader and more capable API set.
>> We've had a platform for years that can build [RIA] that are extremely sophisticated.

Capable, yes. Practical, no. C++ has a capable API set and can build extremely sophisticated applications... That doesn't make me want to use C++. Flash is popular because it's accessible and gets the job done with some flair. I actually don't like Flash all that much (as a user and a developer). But at least the people behind it aren't completely clueless about the wants and needs of the market.

>> If you think you can do something better, then please ship it.

Nice.

One of the more compelling parts of using Flex is the ease of integrating the Flash UI with a Java backend. So, it is a big nothing to still make use of the protocols available in Java on the backend. Making a UDP call or sending an email from a MXML page (flex page) would be like coding this into a JSP page. In most every Java application I have worked on that is a no-no, as most architectures delegate these types of things to the backend anyway. So, are you really loosing anything here? Or, are you just eliminating the ability for developers to code business logic in the wrong tier?

I recently worked on a project that chose Java Web Start over AIR in part because there didn't seem to be a robust implementation of FTP at the time.

Also, we recently considered a Flex front end for REST services only to find out that Flash can't easily support all HTTP verbs without an intervening proxy.

So I guess, yeah, it is.