Summary
If so, this is a call to action.

If I understood it right, this was supposed to be the "year of Java FX" at Java One. We were going to be stunned by how clever and clear Java FX is. Instead, there seems to be deafening silence in the blogosphere.

The history of Java UI is littered with disastrous decisions, starting with the AWT (Abstract Windowing Toolkit), which was created at the last second, because (no surprise) the language designers hadn't considered UI as an important paradigm for Java. Rumor has it that AWT was one month from conception to completion, which certainly fits. The results of AWT -- buggy and equally mediocre on all platforms -- destroyed everyone's faith in Java UI, for so long that Swing, which has been baking for years and years, is only just getting back some of the lost mojo. Users, who have a long memory of first impressions, still equate Java with crappy user interfaces, so to them the steaming coffee cup looks like something else that steams.

Then there's the steadfast refusal to support a component and event model in the language. No, Java Beans is not that; it's a weak attempt to fill in the gap. A true component and event model is far different from requiring the programmer or environment to spew out lots of code to emulate it. If that was the solution to everything, we'd never need abstractions; we might as well just say that a basic Turing machine will solve all problems.

And Swing programming has never been easy, but always messy and complicated. There were periodic murmurs of trying to make Java UI programming as easy as Visual Basic; at one point, Sun even had a VB porting project but abandonded it. Without the underlying infrastructure it can't ever happen. You'll always end up with lots of tedious UI code.

Basically, UI programming in Java has always been an afterthought, reluctantly accomodated but never really supported. It's no wonder that people are taking a wait-and-see attitude about Java FX.

How many well-known Java desktop applications are there? Well, there's Eclipse, a development environment, which created its own UI library because Java didn't satisfy the needs at the time. There's NetBeans, a development environment, which shows that Swing is now up to the task. And there's IntelliJ, a development environment. But I don't know of any general desktop apps in Java, especially ones that people pay for.

The reason people don't seem to create consumer and business desktop applications in Java may in fact be the UI debacle.

I've been studying Flex on and off for several years now and I continue to find it to be the best all-around solution for UIs, especially because I'm not trapped using a single language for the back-end logic. Flex was designed from the ground up as a user-interface language. The use of Flex as a UI solution for multiple languages has been expanding because people have been creating AMF (ActionScript Message Format) bridges for their favorite languages.

AMF is an ideal approach because it is asynchronous, so it fits well with the UI paradigm. In general, you never know how long something is going to take, and the asynchronous approach guarantees that your UI is always responsive no matter what is going on.

I've shown an example of PyAMF in this article. The PyAMF project appears to be quite active and well-maintained, and provides a straightforward solution for creating UIs for desktop Python applications.

RubyAMF also seems to be a very active project. It creates Flex user interfaces for Ruby on Rails apps, but there was a presentation at the last RailsConf on "Powering AIR Applications with Rails," so it would seem to support the desktop paradigm, as well.

There's also an AMFPHP project for PHP, although this is not a desktop solution.

There is an OpenAMF project for Java-Flash remoting, but it appears to be dead, with the last activity being 1.0 Release Candidate 12 in April 2006. The product doesn't work with more recent versions of Java, and no one appears to be maintaining it. Which is interesting because Java should theoretically be a much larger base and in that vastness there should be a group of people who want this -- I certainly do. Even more so because BlazeDS is open source and contains the core workings of what you need to create Java AMF (BlazeDS itself is only designed for Java web apps).

I don't know this for sure but I think at some point Adobe extended the olive branch to Sun regarding connecting Java and Flex beyond BlazeDS, but as usual, Sun couldn't see beyond their "not invented here" motto and had to create something "better." So now everyone appears to be taking a wait-and-see attitude, wondering whether Java FX is going to be another "greatest thing in the world, just you wait" that never materializes (perhaps Sun, in all of its tussles with Microsoft, has learned far too much about that company's marketing practices).

My first preference would be that Adobe would create and maintain a Java-AMF bridge for desktop applications, but perhaps Adobe considers Java a server-only technology; in any event, desktop Java support doesn't appear to be forthcoming from Adobe (I'd love to be surprised about that one). Perhaps their focus is on competing with Silverlight (I'm definitely waiting-and-seeing on Silverlight. Microsoft always promises big, but what they actually deliver is often very different -- consider Vista).

So if people are really interested in desktop Java, prove it. Take the work that's already been done in the open-source BlazeDS and create a desktop Java-AMF bridge, so we can easily add AIR user interfaces on top of Java code. That way you can have easy-to-create UIs now, instead of waiting to see whether Java FX pans out.

Talk Back!

Have an opinion? Readers have already posted 103 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Bruce Eckel adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Bruce Eckel (www.BruceEckel.com) provides development assistance in Python with user interfaces in Flex. He is the author of Thinking in Java (Prentice-Hall, 1998, 2nd Edition, 2000, 3rd Edition, 2003, 4th Edition, 2005), the Hands-On Java Seminar CD ROM (available on the Web site), Thinking in C++ (PH 1995; 2nd edition 2000, Volume 2 with Chuck Allison, 2003), C++ Inside & Out (Osborne/McGraw-Hill 1993), among others. He's given hundreds of presentations throughout the world, published over 150 articles in numerous magazines, was a founding member of the ANSI/ISO C++ committee and speaks regularly at conferences.