Working with Swing
Our introduction to Swing wouldn’t be complete unless we briefly mentioned some caveats of the Swing libraries. There are two pertinent areas: multithreading and lightweight versus heavyweight components. 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, Sun posted an article recommending that developers not use independent threads to change model states in components.[2] Instead, once a component has been painted to the screen (or is about to be painted), updates to its model state should occur only from the event-dispatching queue. The event-dispatching queue is a system thread used to communicate events to other components. It posts GUI events, including those that repaint components.
The issue here is an artifact of the MVC architecture and deals with performance and potential race conditions. As we mentioned, 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 may 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 ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access