This is by design to allow UI and models to be unsynchronized by default, and you can use various multi-threading trickeries to support doing multiple things at the same time, namely to retain UI control and having some work done in the background.
However, the lack of communication between the UI thread and spawned worker threads can be difficult to tackle, such as when a worker thread finishes its task, the UI is not in the right/expected state, such as the user has switched to another panel, and cannot accept the output of the job.
I am wondering if the authors of FRC finds this a problem that needs to be addressed. Suppose a user clicks on something to spawn some fancy animations, and before the animation is completed, the user clicks on a tab to switch away, potentially causing NPE or unexpected exceptions. [ September 18, 2007: Message edited by: Chu Tan ]
As Ulf pointed out, this is not a problem with Swing, but rather a reality of most/all UI toolkits. Every tried to execute a long-running task inside the button-clicked event in a win32 application? You'll get the same app-frozen effect. The trick is to figure out how to take advantage of Java's threading model to make sure that your UI is snappy (handling only UI-specific tasks) while the non-UI logic happens elsewhere.