Making Swing components synchronized

I'm reading Java Threads 3rd Ed. by Oaks and Wong (O'Reilly 2004). They carry an example of a Swing typing game throughout the book. The classes they define are mostly cus开发者_JAVA技巧tom subclasses of javax.swing.JComponent.

What seems quite wrong to me is that they make those JComponents thread safe with various synchronization methods. I was under the impression that Swing components should not be thread safe, but rather that they should always be accessed from the Swing event dispatching thread. (Amusingly, one of the few times where they modify a component through the Swing EDT, it's for a setText, which is one of the very few Swing methods that do not need to be called from the EDT.)

I would like to know from some of you who have a lot of experience writing/reading Swing code: Is it common for programmers to make Swing components synchronized instead of always modifying them through the EDT? Is it tolerable?

EDIT:

I noticed it is nearly the same question as this thread. However it does not say what programmers actually do in the wild. I'm puzzled that an O'Reilly book would so blatantly violate the Swing threading model.

EDIT:

I discovered that they do briefly explain somewhere in the middle of the book the Swing threading model. Nonetheless I'd like to have an answer to my question. I have the feeling most who read this book will end up violating the Swing threading model since most of their examples do.

EDIT:

If you want to look at the code, you can Download examples code as a zip file. See for example ch03/example1/AnimatedCharacterDisplayCanvas.

EDIT:

I just learned that setText will not be thread-safe in Java7 (release in July 2011).

---

Trivially, as long as the synchronized methods do not execute on the EventQueue, they won't block the event dispatch thread. Conversely, a method executing on another thread should always use the EventQueue to dispatch code via invokeLater(), invokeAndWait(), or a related mechanism such as javax.swing.Timer or javax.swing.SwingWorker. As a practical matter, these are reliable. The examples may be correct, but they should be examined from this perspective.

The EventQueue API says, "The only requirements are that events...are dispatched...in the same order as they are enqueued." In my opinion, this is tantamount to the "happens-before" relation of java.util.concurrent and the JLS. A more detailed discussion may be found here.

---

You should never have synchronized blocks on Swing components, its going to cause weird problems when its trying to be rendered.

Swing is not thread safe because everything is supposed to be updated on the EDT, even creation of Swing components.

Long running processes should be moved to a background thread or a SwingWorker. When a thread other than the EDT needs to make components or make updates to a component it should be wrapped using SwingUtilities.invokeLater()

---

"Swing components are not inherently thread safe, and as a general rule, after Swing components have been made visible on the screen, you can only safely modify their data from the event thread. If you modify Swing component data from any thread other than the event dispatching thread, you must take precautions to ensure data integrity. An exception to this rule is the setText method on a JTextComponent or any of its subclasses, or any Swing component method whose documentation explicitly states it is thread safe." Monica Pawlan http://java.sun.com/developer/technicalArticles/Threads/swing/