Related Topics: RIA Developer's Journal, Java Developer Magazine, AJAX World RIA Conference

RIA & Ajax: Article

SWING

Its past, present, and future

The Napkin Look and Feel is an extreme example of what's possible with a custom Swing look and feel. It was written so that early versions of desktop applications with provisional GUIs wouldn't give anyone the mistaken impression that the application was actually finished. It's also pretty funny (see Figure 3).

There is a lot of interest in technologies like AJAX and Web 2.0 that enhance the browser experience to be a richer user interface experience. Do you see this as a threat to Swing?

It wouldn't be honest to say that we don't feel somewhat threatened by AJAX or any of the other desktop client technologies that are competing for developers' attention, tools support, and recognition in the finer trade and technical periodicals. On the other hand, competition is healthy and the growth in user's expectations of Web-based desktop application plays to our strengths.

Some of the advantages of Swing applications are:

  • Can run online or offline.
  • Native look and feel if you want it.
  • High-performance 2D and 3D graphics.
  • Support for visualization and direct manipulation of large data sets. No paging through tables of results or waiting for the server to compute the presentation of the next bit of data.
  • Full access to the desktop (for signed apps).
  • The Java software platform is deep and wide. Threads, collections, security, database, XML - there's an entire article here.
  • Integration with the client OS desktop, like drag-and-drop with other applications.
  • Hundreds of component libraries, lots of tools, large robust Java developer community.
Some companies moved away from desktop apps toward Web-based frameworks simply for ease of deployment. What is going on in JNLP to help people who want rich desktop applications with a simple one-touch deployment that has the same ease of use as a browser URL?

Easier deployment continues to be a focus for the desktop group.

One aspect of simplifying deployment is making sure that, in most cases, Java SE is already installed on users' PCs. To that end, we have bundling agreements with the top ten (and many more) PC OEMs, and we're getting new OEMs signed up all the time. At this point the majority of new PCs come with Java SE 5 pre-installed. We're also seeing phenomenal download rates: in the last 12 months we've served up about a quarter of a billion downloads. That's a lot.

For platforms that do not already have Java installed, we continue work on easy-to-use mechanisms for installing Java SE and for launching Java SE applications. Back in June, we published an article about the auto-install features that are part of JDK 5 (http://java.sun.com/developer/technicalArticles/JavaLP/javawebstart/AutoInstall.html). The article discusses an ActiveX component for Windows/IE that detects whether Java is installed, checks it against a desired version, installs Java if necessary, and launches a given Java Web Start application. There are also various JavaScript mechanisms that can be used to detect Java on browser platforms and help the user to install and launch Java as appropriate.

This is the model we'd like to work toward going forward: developers should be able to deploy their applications and applets in such a way that the browser can detect whether the user needs to install Java, and, if so, will perform that installation for them and launch the application.

We expect to develop and deliver modules and approaches to assist with this going forward; look for more articles and deployment components in the future.

Both Microsoft and Adobe have implemented declarative GUI programming (XAML and MXML, respectively). Are there similar plans at Sun for the future Swing versions?

There are some good open source languages that we've been keeping a close eye on. JAXX (www.jaxxframework.org/), in particular, is quite similar to Adobe's MXML - it is fully compiled, has nice data-binding features, and is styled using CSS. The biggest difference from MXML is that instead of using ActionScript and Flash, JAXX uses Java and Swing, so it's both faster and more powerful.

It's hard to say if Swing will ever directly incorporate a declarative UI language, but the open source solutions that exist today are definitely worth a look.

How do you see the relationship between Swing and SWT both at the moment and moving forward?

On a personal level the relationship between the two teams is friendly as can be plainly seen in the undoctored photo in Figure 4.

When SWT first debuted, we made some changes to ensure that Swing components would work within SWT applications; however, mixing two GUI toolkits in a single application is notoriously difficult. Over the years demand for a bridge has persisted within the Eclipse/RCP community, however, the technical problems haven't become any simpler. Nevertheless the two development teams have settled into a peaceful coexistence.

How important do you think IDE tools are for the adoption and usage of Swing?

For the longest time we've held the line at, "We do the API, tool vendors write the tools." That's led to some embarrassments on our part in the form of untoolable APIs and difficult or unusable tools; not good! XEmacs and vi are certainly enjoyable, but if you ever want more than rocket scientists to use the platform, you need compelling tools. Thankfully we've awakened to this fact.

For Java SE 6.0, we've worked closely with the NetBeans folks to address one of the hardest problems in Swing: layout. This partnership has resulted in a world-class tool, Matisse, that makes it trivial to create visually appealing layouts. With Matisse, you no longer need to know about layout managers, instead the user focuses on arranging the components in a way that is immediately familiar to nearly all developers.

We will continue to work closely with NetBeans and other tool vendors to make sure new APIs are toolable. The expert groups for 295 and 296 have numerous tool vendors on them, including companies such as Oracle, JetBrains, and Borland.

There was a lot of interest at JavaOne in the timing framework and some of the very polished demos, especially the keynote flickr demo and the Extreme makeover e-mail client. Are these available for developers to download the code and see what was done under the covers ?

The code for the extreme demo e-mail clients will be made available later this year; look for announcements about that on javadesktop.org. Aerith, the Flickr/Google Maps demo shown during the keynote, was released online at aerith.dev.java.net. As you can see in Figures 5-7, Aerith is quite a looker.

We weren't able to release the Aerith demo quite as promptly as last year's SwingLabs JavaOne keynote demo. That one was actually released while the keynote presentation was underway. This year there was a bit of delay because the SwingLabs team wanted to clean up the code to make it a little easier for other developers to learn from it. Though it took more time, we think it was worth the wait. The source for many of the components that went into Aerith are available in their own projects including JOGL (Java bindings for Open GL at jogl.dev.java.net), the mapping component (swingx-ws.dev.java.net), and the animation framework (timingframework.dev.java.net).

Chet Haase: Did someone say animation? [Editors note: At this point the interview was interrupted by the appearance of a marching band led by (drum major) Chet Haase. It took a while to get the brass section to quiet down, and to make Chet stop leaping around and twirling his baton. Eventually we were able to resume the interview.]

The Timing Framework, in particular, is not specific to Aerith, but is instead a general framework that simplifies creating and running animations. The core facilities of java.util.Timer and javax.swing.Timer leave much to be desired in terms of the amount of work a developer must do to actually use animations in a Swing application. This probably helps explain why there are not many Swing applications that use animated effects. Hopefully, with the Timing Framework, we can help change that and make it easier for Swing developers to write dynamic applications that use animated effects.

The framework is still in flux, but the current project site has working code that we encourage you to check out and use. In the meantime, we are refining the API and capabilities to make it more powerful as well as more easy to use.

If you could re-do Swing all over again, what would you do differently and why?

Rather than just provide one answer to this question, we decided to give every person who'd worked on the Swing project at Sun a shot at it. The first response rolled in less than five minutes:

James Gosling:

  • Delete half the methods. The "747 cockpit control" thing got way out of control (i.e., just do the things that actually matter, not all the things that someone thinks could possibly matter in some obscure case)
  • Rethink events and listeners; e.g., there are way too many addXxxListener() methods.
  • Make JOGL part of SE and integrate it more cleanly with 2D.
  • Get rid of 1.0 compatibility!
  • Get rid of deprecations!
  • Building new L&Fs is too hard. This is one of the areas where it feels like we overgeneralized
  • Fold in a pile more standard Choosers (take all of the cool stuff in javadesktop.org and fold it into SE).
Ouch. Fortunately, not 10 minutes later, another response rolled in from left field:

Chet Haase:
I would have sold SUNW at $63.

Over the next two weeks, many more responses rolled in. Some pithy, some painful, a few funny, and a rare gem that was a nice combination. Here's a sampling:

Steve Wilson (original Metal L&F author, now a Sun Microsystems Vice President):

We should have written (and shipped) our own GUI builder in Swing in tandem with building the toolkit - which we didn't do because we were too worried about hurting Symantec and Borland's Java tools businesses. Boy, in retrospect, it's good thing we didn't hurt those! Oh, wait...

Phil Milne (original author of JTable among many other contributions):

My first memory of life on the Swing team was the moment when I uncovered the 20 classes that performed the role of the Button class in NeXT's appkit. Soon the mystery was solved when kind colleagues patiently explained Swing's architecture and how it laughed in the face of common technical problems such as your Apple desktop spontaneously turning into a PC. Imagine my surprise when I checked my diary the other day to discover that the number of times this had actually happened to me over the last eight years was zero! A more AppKit-like API then: smaller, lighter, faster and designed to work well with a GUI builder.

Romain Guy (Synth L&F developer, the mad genius behind countless demos, etc...):

Real quick cause I'm leaving for China in a few hours. I would make Swing entirely vector-based (i.e., resolution independent) with as many built-in effects and animation support as possible.

Rick Levenson (first engineering director for the Java SE desktop groups):

If I could re-do Swing all over again, I would make sure this time to actually contribute something more meaningful than just my bouncing head...(see Figure 8).

Arnaud Weber (all-around early Swing developer and performance tuner):

If I could re-do Swing all over again, I would spend more than one week on ComboBox. Seriously, I believe I would focus a lot more on building a real application framework instead of simply delivering a graphical user interface toolkit. I would also greatly simplify all the type-safe listeners and replace them with more generic notifications. In my opinion, all these small inner classes in the client code not only have a performance impact but also make everything more complicated than necessary.

Scott Violet (long time Swing tech lead and architect):

I wish I knew how to spell; every time I see insertAtBoundry (HTMLEditorKit.InsertHTMLTextAction) and insureRowContinuity (DefaultTreeSelection) I feel ill.

This last response caused current Swing engineer Alexander Potochkin to bring up the following backwards-compatibility embarassment that we'd all prefer didn't exist:

// from java.awt.event.KeyEvent
public static final int VK_SEPARATER = 0x6C;
public static final int VK_SEPARATOR = VK_SEPARATER;

Of course it didn't end there. There were followups and escalations; the e-mail thread is probably still sputtering away as you read this, but we'll spare you.

What are the most important things that are going to occur in Swing over the next five to 10 years?

In five to 10 years, in addition to tooling around in ethanol-powered flying cars, we expect users to be interacting with computers via datagloves and contact lenses with LCD displays. By then, the large glass panels Tom Cruise bossed around in "Minority Report" will look as old fashioned as teletypes and paper tape.

Seriously though, it's pretty clear we will need to continue to work on making Swing, and the Java platform as a whole, easier to use. We've begun work down that path with JSRs 295 and 296; there are many other things that could be done.

We've all been impressed by how popular AJAX has become in such a short time. At least part of its popularity stems from the relative ease with which you can reuse what others have done in novel ways. For example, we've all come across Web sites that make something new from Google maps. We've got to do the same for Java and Swing. We need to make it trivial for newbies to get apps up and running in hours, not days or weeks.

A key part of this change will be tools. No one wants to read thousand page tomes anymore! Developers want to start up a tool and in a matter of hours have something compelling that's just a button press away from being deployed on the Internet. That is what we have to strive for.

We recently saw a slide that showed how growth in GPUs is outpacing growth of other components of a computer. We'll continue to look for ways to make better use of GPUs in applications. You can see this in Vista and Leopard - rich animation and graphic effects in nearly every app. While we plan on doing work in this area for Java SE 7, I suspect we're just seeing the tip of the iceberg as far as what is possible.

Another desktop trend that's going to have a big impact on what desktop applications can do is the number of CPU cores in typical machines. Today, machines with two cores are common. Given the ruthless more/bigger competition in the PC business, we can probably expect desktops with dozens of cores in 5-10 years. This is already reality in the server world and Java's extensive support for threaded programming will serve us well. Making it possible, even easy, for Swing app developers to harness all of that parallel power will be a challenge for us in the years ahead.

Our developer community will continue to be an important ingredient in whatever we do. You, as the end developer, know what is best for your problem domain. By working closely together we can make sure whatever we develop addresses both needs. The JDK development community has been tremendously successful in this area, and we continue to look for new ways to make it better.

What's the best place to learn more about what's happening in Swing and to stay abreast of all the new features?

For official documentation and articles, please see the Java Desktop Web pages on java.sun.com: http://java.sun.com/javase/technologies/desktop.

You can not only stay abreast of new features but can actually participate directly in the future of Swing by looking at and joining the SwingLabs project on java.net: www.swinglabs.org.

We'd also like to urge you to read javadesktop.org daily, where you'll find several Java Desktop luminaries (from both inside and outside Sun) blogging, as well as newsfeeds, discussion forums, and product announcements by developers using Java desktop technology: www.javadesktop.org.

Contributors to this article include the following past and present members of the Swing team:
Richard Bair
Chet Haase
James Gosling
Romain Guy
Michael Knyazev
Rick Levenson
Josh Marinacci
Phillip Milne
Hans Muller
Ethan Nicholas
Alexander Potochkin
Scott Violet
Steve Wilson
Arnaud Weber
Jeff Dinkins
Shannon Hickey
Igor Kushnirskiy
Tim Boudreau
Thorsten Laux

More Stories By Hans Muller

Hans Muller is the CTO for Sun's Desktop division. He's been at Sun for over 15 years and has been involved with desktop GUI work of one kind or another for nearly all of that time. He's been involved with the Java project since its earliest days and led the Swing team and later all of the client Java work at Sun.

Comments (3) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Curt Cox 10/09/06 11:50:25 AM EDT

"Prototype implementations of the APIs will be evolved out in the open, and we plan to make versions available for the current Java SE 5 and Java SE 6 releases."

We're eagerly awaiting the initial release.

JDJ News Desk 09/29/06 07:26:35 PM EDT

Nearly a decade ago, when Java was still a fledgling portable software platform and the Tumbling Duke applet was considered cutting edge, the members of the newly minted Swing team, including yours truly, took in a packed JavaOne session given by Sun's JavaSoft president, Alan Baratz. He told the assembled multitude that our team would be delivering a new GUI toolkit in just 90 days. Although we'd been working on what was called a 'lightweight toolkit' for some time, he hadn't bothered to mention the new project deadline to us. Until that moment. If there'd been enough room, we would have all fallen off our chairs.

JDJ News Desk 09/29/06 05:10:20 PM EDT

Nearly a decade ago, when Java was still a fledgling portable software platform and the Tumbling Duke applet was considered cutting edge, the members of the newly minted Swing team, including yours truly, took in a packed JavaOne session given by Sun's JavaSoft president, Alan Baratz. He told the assembled multitude that our team would be delivering a new GUI toolkit in just 90 days. Although we'd been working on what was called a 'lightweight toolkit' for some time, he hadn't bothered to mention the new project deadline to us. Until that moment. If there'd been enough room, we would have all fallen off our chairs.