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, ...
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