threads and Swing dialogs

Mark McCulley
Right Side Development

All applications and components share the same event-dispatch thread.
Normal dialogs are no exception. Modal dialogs (and FileDialogs), on the
other hand, need some undercover slight of hand to prevent the event queue
thread from blocking if it is the one showing the dialog.

The way this has been done in the JDK AWT has been to kick off a new
event-dispatch thread before showing the dialog (and blocking in the peer)
and then telling that thread to stop dispatching once the dialog is
dismissed. This does not work perfectly and we are probably all ware of the
various modal dialogs problems that have existed in different
implementations.

Swing uses a different technique in which if the event-dispatch thread
shows the dialog it effectively, after displaying the dialog in a
non-blocking manner, executes the event-dispatch thread main processing
loop, ie. as long as the dialog is being shown the thread takes events from
the event queue and processes them. One the event that dismisses the dialog
occurs the dialog will no longer be visible and the event processing loop
will terminate; the event dispatch thread then continues where it left off,
processing the original event.

Note however that whilst this blocks the thread as required, it currently
doesn't actually disable input to other components. This will be fixed
before the final release - so they say. :)

A final note is that you shouldn't (as an application programmer) need to
care about how modal dialogs are handles. In practice though the use of a
new event dispatch thread can lead to synchronisation problems if your
event handling methods use synchronisation locks. Of course with swing this
should be unnecessary because you're not allowed to have multiple threads
accessing your GUI components.

David