Wizard API updated!
Tim Boudreau has released a new version of the Swing Wizard library (version 0.997) that fixes the WizardException bug reported in JavaWorld's recent Open Source Java Project profile. The article's examples have been reworked to test out the new, improved WizardException. Thanks, Tim, for this helpful fix!
Open Source Java Projects: The Wizard API

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com > Java Standard Edition >

Customize SwingWorker to improve Swing GUIs

Discover techniques and best practices for robust user interface development

By Yexin Chen, JavaWorld.com, 06/06/03

Since its inception in JDK 1.2, the maturing Swing toolkit has become an attractive alternative to thin-client presentation technologies such as JavaServer Pages (JSP), JavaScript, and HTML. Swing offers the benefits of portability, code reusability, and ease of maintenance, especially when the solution requires a rich user interface (UI) that is deployable in a controlled environment. For instance, Swing developers need not worry about browser compatibility issues; they can instead devote more time to improving component functionality and application usability.

Despite these favorable attributes, the Swing toolkit has weaknesses. Swing suffers from the inherent limitation of a larger resource footprint and dependencies on the Java runtime environment, thereby complicating its deployment process. The more important issue is that developers should be aware of the UI design goals and Swing's inner mechanics during a project's early phases. Doing so avoids costly redesigns in later development stages. It is good practice to keep in mind the following design criteria when putting together the application user interface:

  • Screen liveliness: The user interface should maximize its responsiveness to user interaction, especially when the application executes other processing-intensive tasks.
  • Presentation integrity: The user interaction with the application should always obtain consistent and predictable presentation results, unless nondeterminism is part of the application logic.
  • Operation feedback: The user interface should accurately inform users of the current application status through visual feedback. Some examples of basic feedback mechanisms are the progress meter and the mouse cursor change.


A great deal of effort may be necessary to factor out the complexities required to achieve these design requirements. This article eases that effort by illustrating best practices through a demo application.

Note: You can download this article's demo from Resources.

Basic Swing concepts review

Let's review the Swing event-dispatch concept, which is the foundation for other topics discussed later. First, when the user interacts with Swing components, whether it is clicking on a button or resizing a window, the Swing toolkit generates event objects that contain relevant event information, such as event source and event ID. The event objects are then placed onto a single event queue ordered by their entry time. While that happens, a separate thread, called the event-dispatch thread, regularly checks the event queue's state. As long as the event queue is not empty, the event-dispatch thread takes event objects from the queue one by one and sends them to the interested parties. Finally, the interested parties react to the event notification by processing logic such as event handling or component painting. Figure 1 illustrates how this works.

Figure 1. Swing event-dispatch model

Since the event-dispatch thread executes all event-processing logic sequentially, it avoids undesirable situations such as painting a component whose model state is partially updated. This is great news for Swing developers because they can assume that only one thread, the event-dispatch thread, will process the event-handling code. If two event-dispatch threads worked on the event queue, Swing developers would need to write additional code for thread safety. Similarly, executing user interface-related code in any thread other than the event-dispatch thread can lead to unexpected behaviors. If it is absolutely necessary to execute UI-related code from a separate thread, the developer should use the following code as a workaround:

1 | 2 | 3 | 4 | 5 |  Next >
Resources