Pinderkent

Although Java's Swing has very little usage in consumer-grade software applications, it is used in a significant amount of in-house business software at many companies, as well as in a variety of system administration tools. While it was one of the major benefits of Java for some time, Swing is really starting to show its age. With it now being roughly a decade old, it's time to start looking for a replacement.

Jonathan Giles recently wrote about what he'd like to see in what he calls "Swing 2.0". His suggestions are excellent. Many of them revolve around updating Swing to make better use of the new language features introduced with newer versions of the Java language.

The use of enumerations is a must. One of the main sources of problems with Swing applications is an incorrect integer constant being passed to a method. The effects of such a mistake can vary significantly, and can often be very difficult to detect and debug. Unfortunately, Swing makes use of integer constants in numerous places. For compatibility reasons, these likely would have to remain as integers. Having a mix of integer constants and enumerations is arguably worse than just having one or the other.

Giles suggests that "Swing 2.0" would be a cleanup of the existing Swing code, with it being ideal if API compatibility could be maintained. My thought is that it's best to not base the updated library on the existing Swing codebase. The existing codebase has served us well (or not so well, in some cases), and given its age should probably be retired.

An added benefit of starting afresh would be the chance to eliminate the dependency on the AWT. In terms of desktop application development, the AWT is basically a relic now at almost 15 years of age. It came about in an age when Windows 95, Mac OS 7, and on UNIX the Motif toolkit ruled the roost. The amount of change since then has been huge. AWT is essentially useless on its own for modern software development, yet we still feel its presence when doing Swing development.

A new version of Swing should probably not take the same approach as that of SWT. Anyone who has worked with SWT knows the criticisms mentioned in the Wikipedia article quite well. Inheriting from existing widgets can be a hassle in many cases, and the manual resource deallocation of some SWT objects goes against the Java mentality of automatic resource deallocation.

However, it would be beneficial if the new toolkit did offer better performance than that of Swing. Giles mentions misuse of Swing's event-dispatch thread as one problem that needs to be addressed. But even well-written Swing applications running on a modern computer often don't feel as responsive as native applications do. A focus on making better use of resources and hardware acceleration may help with this.

Now would be a good time for the development of such a toolkit. Java 5 has become relatively widely deployed over the past few years, so it would be feasible to make use of the new language constructs it offers. And compared to .NET, Java as a platform has stagnated somewhat. A high-quality GUI toolkit may help bring developers back over to Java, or at least renew interest in it.