Java Swing

Working with Swing

Our introduction to Swing wouldn’t be complete unless we briefly mentioned some caveats of the new libraries. There are two areas to briefly mention: multithreading issues and lightweight/heavyweight issues. Being aware of these issues will help you make informed decisions while working with Swing. Chapter 28, gives you in-depth guidance in these difficult areas.

Multithreading

Shortly before the initial release of Swing, JavaSoft posted an article recommending that developers not use independent threads to change model states in components.^[6] Instead, they suggest that once a component has been painted to the screen (or is about to be painted), updates to its model state should only occur from the event-dispatching queue . The event-dispatching queue is a system thread used to communicate events to other components. It handles the posting of GUI events, including those to repaint components.

The issue here is an artifact of the MVC architecture and deals with performance and potential race-conditions. As we mentioned above, a Swing component draws itself based on the state values in its model. However, if the state values change while the component is in the process of repainting, the component can repaint incorrectly—this is unacceptable. To compound matters, placing a lock on the entire model, as well as on some of the critical component data, or even cloning the data in question, could seriously hamper performance for each refresh. The only feasible solution, therefore, is to place state changes in serial with refreshes. This ensures that modifications in component state do not occur at the same time that Swing is repainting any components, and no race conditions will occur.

The Z-Order Caveat: Lightweight and Heavyweight Components

One of the most frequent issues to come out of the lightweight/heavyweight component debate is the idea of depth, or z-order —that is, a well-defined method for how elements are stacked on the screen. Because of z-order, it is not advisable to mix lightweight and heavyweight components in Swing.

To see why, remember that heavyweight components depend on peer objects used at the operating system level. However, with Swing only the top-level components are heavyweight: JApplet, JFrame, JDialog, and JWindow. Also, recall that heavyweight components are always “opaque”—they have a rectangular shape and are non-transparent. This is because the host operating system typically allocates the entire painting region to the component, clearing it first.

The remaining components are lightweight. So here is the crux of the dilemma: when a lightweight component is placed inside of a heavyweight container, it shares (and actually borrows) the graphics context of the heavyweight component. The lightweight component must always draw itself on the same plane as the heavyweight component that contains it, therefore it must share the same z-order as the component. In addition, lightweight components are bound to the clipping region of the top-level window or dialog that contains them. In effect, lightweight components are all “drawings” on the canvas of a heavyweight component. The drawings cannot go beyond the boundaries of the canvas, and can always be covered by another canvas. Heavyweight components, however, are free from this restriction. Therefore, they always appear on top of the lightweight components — whether that is the intent or not.

Heavyweight components have other ramifications in Swing as well. Heavyweight components do not work well in scroll panes, where they can extend beyond the clipping boundaries; they don’t work in front of lightweight menus and menubars (unless certain precautions are taken) or inside internal frames. Some Swing classes, however, offer an interesting approach to this problem. These classes allow you to specify whether the component will draw itself using a lightweight or a heavyweight window. Hence, with a bit of judicious programming, you can keep your components correctly rendered—no matter where they are located.

---

^[6] Hans Muller and Kathy Walrath. “Threads and Swing” on The Swing Connection, at http://java.sun.com/products/jfc/tsc/swingdoc-archive/threads.html.