Question

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?

Answer 1

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…