Rethinking the Java GUI

Simon Phipps, Sun's chief technology evangelist, likens Java to a baby duck. "When Java technology was born, it looked around, saw a Web browser and thought it was an applet," he jokes. His point: Java was miscast as a mobile and portable GUI. Its real mission in life was to become a platform for network services. I thought so too, from the moment I created my first servlet five years ago. I said then:

"It's a peculiar moment in our industry's history. The Java buzz is intense. And yet when you look at the Web applications that people actually use every day to do their work, you invariably find that there are no Java applets in the mix. The universal client today is still the HTML browser. The universal client of tomorrow will be the HTML/JavaScript browser.

Client-side Java is a glorious vision that will not change the way most people use the Internet anytime soon. Why not? It's just more than what the majority of today's computers and networks can readily push. So what are millions of people running every day? Server-based applications that feed the universal HTML client." [1]

That was a contrary thing to say in 1997. It also turned out to be a pretty good prediction. So here's another contrary prediction: Now that we've all written off client-side Java, it may yet prosper. If this were a Gartner report, I would add something like "probability 0.634" -- in other words, I'm not as sure now that Java will fulfill its original mission as I was then that it would prevail on the server. But here are some points to consider.

* Surplus CPU cycles. With ridiculous power to burn on the desktop, it's a lot easier to push layers of Java, including Swing, than it used to be.

* More bandwidth. Our pipes aren't as much fatter as our CPUs are faster, but at the edges of IT-controlled environments dialup is mostly a bad memory.

* Java Web Start. Blurring the distinction between an on-the-fly applet and an installed Java application was a great (and long overdue) idea. It's even possible, using "download='lazy'" in the JNLP (Java Network Launching Protocol) file, to "trickle-feed" classes to the client. (A similar technique can be used for WinForms apps in .Net, by the way).

* SWT. As we noted in a story on Eclipse [2], the Standard Widget Toolkit is seen by some in the Java community as a promising way to preserve the OS-native look and feel of Java more efficiently than Swing can do.

* Java GUI remoting. Despite important advantages, Java Web Start can't reproduce the lightness of the HTML/JavaScript browser. But there are lots of ways to skin a cat. IBM's alphaWorks project offers a GUI remoting library called Remote Abstract Window Toolkit [3], originally for AWT and then more recently updated for Swing. A couple of years ago, the folks at VistaSource showed me Anyware Office, based on the Applixware productivity suite for Linux. For Anyware Office, VistaSource built a lightweight Java GUI renderer that connected, X-Windows-style, to a GUI server and to the guts of the Applixware suite. VistaSource has since focused elsewhere (on real-time data analysis engines), but now smart-client vendor Droplets is aggressively pursuing the concept.