Why is Swing threading model considered wrong and how should it be?
java, multithreading, swing
Solution
Brian Goetz's Java Concurrency in Practice,
9.1 Why are GUIs single-threaded?:
...In the old days, GUI applications were single-threaded and GUI events were processed from a “main event loop”. Modern GUI frameworks use a model that is only slightly different: they create a dedicated event dispatch thread (EDT) for handling GUI events. Single-threaded GUI frameworks are not unique to Java; Qt, NextStep, MacOS Cocoa, X Windows, and many others are also single-threaded. This is not for lack of trying; there have been many attempts to write multithreaded GUI frameworks, but because of persistent problems with race conditions and deadlock, they all eventually arrived at the single-threaded event queue model in which a dedicated thread fetches events off a queue and dispatches them to application-defined event handlers...
Problem
I heard many times that Java Swing threading model is wrong. I don't fully understand why, I know that the problem is related to the fact that you can draw on a `Drawable` from another thread other than the main UI thread. I know that there are utility functionalities like `SwingUtilities.invokeAndWait` and `SwingUtilities.invokeLater` that let you do your painting in a `Runnable`, that in turn is run by the Event Dispatcher thread. I guess that this way you ensure that painting is done synchronously and this doesn't leave the buffer in an incosistent state. My question is: how do "good" UI toolkits behave? What solutions are adopted?