Hans Muller

Subscribe to Hans Muller: eMailAlertsEmail Alerts
Get Hans Muller: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


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

RIA & Ajax: Article

SWING

Its past, present, and future

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.

A rather limited "0.1" Swing release did debut 90 days later. The fact that developers not only adopted this early version of Swing, but actually built applications and even products with it, is testimony to the tidal wave of enthusiasm for all things Java that started in the mid 1990s. Sadly, the reverberations from the initial developer-enthusiasm spike, the one that occurred with Java's debut in 1995, began to fade as the years passed. By late 1998, when we released Swing 1.0 as part of the "Java 2," the Swing team was up to its ears in reality. Performance, native look-and-feel fidelity problems, and the usual bugs were dragging the project down.

Remarkably, the Swing team and the larger desktop client software group persevered. The implementation of the Java client software stack was extensively profiled and tuned, and by the next major Java release, performance was respectable. In subsequent releases, performance ceased to be an issue at all. Native look-and-feel fidelity and robustness concerns have also fallen by the wayside. In JDK 5 and subsequent JDK releases, the task of rendering native components has been delegated to the native GUI toolkit, so Swing looks just as native as the natives on Linux, Macintosh, even Microsoft Vista.

New software fashions tend to have a half-life of about 18 months. After that the books start to move to the discount bin, the conferences go quiet, and developers move on to the next big thing. Swing has not suffered that fate. As the software has stabilized and improved over the years, it has attracted a loyal and growing community of developers who've built tens of thousands of applications deployed to millions of users. No less of an authority that Evan's Data Corporation has reported that "Java Swing with 47% use, has surpassed WinForms as the dominant GUI development toolkit." Not bad for a (nearly) 10 year old.

Joe Winchester, the Java Developer's Journal Desktop Java Editor, thought it would be interesting to take stock of Swing's future in an interview-style article and, naturally, we were happy to oblige. Joe provided most of the questions and various members of the Swing team, past and present, have provided answers.

The Desktop Java track at JavaOne 2006 was one of the best attended and there was a lot of interest around Swing. This seems a little surprising, given all of the hoopla surrounding new software trends like AJAX, and the debut of Java EE 5.

There are various ways to slice the data from JavaOne, like the number of attendees in our sessions, the relative popularity of our sessions, the ratings for individual talks, and the average ratings for our track overall. We were quite pleased with all of these metrics: the attendance numbers were great, the sessions were popular, the Desktop track had some of the top-rated talks in the conference, and the Desktop track overall was near the top of all tracks.

However, our favorite metric to wax poetic about this year is this: our participation from external speakers was higher this year than ever before. For example, in 2005 we had something like 11 Sun talks and eight external talks. This year, we had only six Sun talks and 14 external talks.

There are a couple of takeaways here, but the most interesting one in the context of this article is that we accepted a majority of external talks because people are doing some seriously great stuff with Desktop Java, and had some excellent and deep talks about their work. This included interesting case studies, as usual, but it also included some wonderful presentations on real-world development needs, such as Swing frameworks, data binding, or threading. The fact that there are known experts in the world like Ben Galbraith, Karsten Lentzsch, and Scott Delap who can give in-depth views into how to deal with this stuff is fantastic; it means that there is a growing community of people who know the platform well, and that JavaOne is not just about Sun evangelizing its platform.

We're hoping to see another excellent set of presentation submissions this year; let's keep that Desktop track momentum!

What are the right ingredients for a renaissance in Swing, and do you think they're there at the moment?

It's possible that we're in the middle of a Swing renaissance, although the evolution of the Desktop Java platform and the growth of its use has been pretty steady for a longer period of time than the typical technology era.

There clearly has been a renaissance of desktop user expectations recently, and Swing does fit rather nicely into that. Web users are no longer satisfied with glorified interactive brochures; they're demanding the same rich interactive experience they've always had with standalone desktop applications. Web-started Swing applications (even applets) provide that. Modern desktop applications also depend more and more on data pulled from various Web services. To provide dynamic, directly manipulatable visualizations of data drawn from the Net requires many things, not the least of which is support for highly threaded desktop applications. Swing and Java SE provide extensive support for this kind of work.

Tell me about the SwingLabs project. What are its aims, and how do you see it working alongside mainstream Java SE development.

SwingLabs is an open source project on Java.net that provides tools and libraries to help you make your Swing apps better. Swing Labs is entirely desktop focused and the name tries to express the idea that some of the projects may eventually make it back into Java SE. The SwingX sub-project, for example, has a date picker, an error dialog, an Outlook style task pane, and a sortable table model. These are components people have been wanting for years. Some or all of these may make it into future versions of Java, but you can try them out now at swinglabs.org.

SwingLabs has subprojects for other cool things like animations (the Timing Framework), working with threads (SwingWorker), using the native Web browser (the JDIC project), and working with mapping and Web services (the SwingX-WS project). You can find SwingLabs at www.swinglabs.org and swingx.dev.java.net.

There is a lot of interest in projects like data binding and the application framework. What is the thinking behind these?

Both of these JCP standard efforts, JSR-295 and JSR JSR-296, respectively, have the same overall goal: simplify building Swing applications. Both projects aim to do so by eliminating much of the boilerplate code required by common application types.

JSR 295, "Java Beans Binding," trivializes keeping a pair of properties in sync, including automatic type conversion and validation. It also provides support for Java collections, database types like RowSets and (new in Java SE 6) DataSets, and Swing component models.

JSR 296, "Swing Application Framework," provides support for common application elements, notably resources and actions, as well as the application startup/run/shutdown lifecycle. Simplifying resource injection and writing multithreaded applications are significant goals.

We're hoping that the work on JSRs 295 and 296 will be completed in time for the Java SE 7 release. 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.

The work on these JSRs reflects a trend. We're focusing more of our energy on providing higher-level support for application building.

Does this mean that Swing is moving beyond just being a GUI toolkit toward a more complete solution?

Yes. We look forward to a future where all applications will be built with Swing. From accounting software to computer vision systems, all software will be Swing, all the way down. In fact, we don't plan to rest until all things, from laundry soap to city governments, from fast food to artificial limbs have been created with Swing. The complete solution will make Swing literally the fabric of our lives. We're marching towards intergalactic Swing domination.

Ahem.

[Note to editor: Please consider the previous statement off the record.]

When you consider the overall desktop client stack, the extensive support for graphics and internationalization and deployment, and beyond that the overall Java SE platform, networking, and threads, and database access, and all the rest, what we're really up to is trying to simplify building complete solutions. All of the building blocks are there; what's important is making it easy to put them together.

Two important aspects of that are up-leveling, which was mentioned earlier, and "toolability." Historically, we have not been particularly strong on the tools front, supporting Swing in tools has required a great deal of custom work. There's no silver bullet for fixing that, and most GUI toolkits make similar demands of tools. However, we are mindful of the need to create APIs that take tools support into account. The GroupLayout layout manager, which was designed with direct manipulation GUI layout design in mind, is a good example of that.

Some developers like to use Swing to create very high- fidelity desktop applications and shy away from its emulated widgets, whereas others seem to enjoy its lightweight flexibility to produce very creative and rich user interfaces with dynamic content. Which set of users do you most see as your target user?

With Swing, it's possible to have your cake and eat it too. If you want your buttons to look exactly like native buttons on Vista, we support it. If you want your buttons to look like squishy Jelly Bellys (tm), we support that too. The ability to support multiple look and feels is core to Swing's design.

In the early releases, Swing's rendering of platform-native components was off in a number of areas, and we got our collective ears filled with complaints about that. As of JDK 5 update 8, we've fundamentally changed the way native L&F components are rendered on Windows. Swing on Windows XP (and on the upcoming Windows Vista release) uses the native UXTheme API to render components. This means there's no guessing or mimicry. GUI components will look exactly like their native counterparts because they're rendered by the same code. This approach also works nicely for Windows desktop themes, even third-party visual styles. When Vista finally ships, Swing apps will look native. You'll see similar changes, based on the GTKStyle class, for Linux and Solaris in the JDK 6 release.

The SwingSet demo screenshots (see Figures 1 and 2) were made on Windows XP, and an early beta of Windows Vista.

For those developers who want a unique look to their application, there are many options. Synth makes it much easier to create a custom look and feel from scratch. You can also buy or use a third-party look such as Plastic or Alloy. And, of course, you can write your own Swing look and feel from scratch. If those approaches sound like too much work, it's easy to customize individual component classes, to change their behavior, add animation, whatever you can think of.


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.