How can Swing dialogs even work?

Question

If you open a dialog in Swing, for example a JFileChooser, it goes somewhat like this pseudocode:

swing event thread {
  create dialog
  add listener to dialog close event {
    returnValue = somethingFromDialog
  }
  show dialog
  (wait until it is closed)
  return returnValue
}

My question is: how can this possibly work? As you can see the thread waits to return until the dialog is closed. This means the Swing event thread is blocked. Yet, one can interact with the dialog, which AFAIK requires this thread to run.

So how does that work?

Idiom

Answer 1

It's the AWT's thread, not Swing's.

Anyway, AWT runs the dispatch loop within the show. Input events to blocked windows are blocked. Repaint events, events to unblocked windows and general events are dispatched as usual.

You can see this either by adding the line:

 Thread.dumpStack();

into the even handling for the modal dialog, or more easily from the command line with jstack or use ctrl-\/ctrl-break in the command window of the application.

The Foxtrot library abuses this to provide a more procedural (as opposed to event-driven) model. It's also used by WebStart/Java PlugIn to provide dialogs for JNLP services and others when called from the application EDT.

Battista

Answer 2

The existing event dispatch thread is blocked, and so swing creates another thread that pumps the events. This is then the event dispatch thread for the duration of the dialog.

Swing creates a separate native thread for pumping native OS window messages. This is separate from the AWT event thread.

On Windows, you see these threads

  "AWT-Windows"   - the native UI thread
  "AWT-EventQueue-0" - the current AWT event dispatch thread

EDIT: The downvote is correct. This is not true, at least not in all cases.

Modal dialogs often take care of pumping AWT events themselves. If you run the code

SwingUtilities.invokeAndWait(new Runnable()
{
    public void run()
    {
        JOptionPane.showInputDialog("hello");
    }
});

and then break, looking at the threads, you will see only one EventQueue thread. The show() method of JOptionPane pumps events itself.

Frameworks like Spin and Foxtrot take the same approach - they allow you to create a long running blocking method on the EDT, but keep the events flowing by pumping events themselves. It is possible for swing to have multiple dispatch threads (I'm sure this was the case with older versions of swing) but now that multicore is common, the concurrency issues, in particular ensuring changes on one thread are correctly published to other threads, mean that using multiple EDTs produces bugs in the current implementation. See Multiple Swing event-dispatch threads

Acidity

That explains things. Upvoted your answer but somebody else downvoted both :-/ – Idiom

An edit should fully correct the information, or remove the incorrect info. No point stating something for others to read and then noting afterwards "the above is not true". The aim of SO is to build up a knowledge-base of quality answers. – Equidistance

No new thread is started; the 'paused' code stays there on the call-stack, and the code enters into a new EDT event-processing loop, which can continue to process GUI events, paint windows and so on. 'OK'ing a modal dialog exits the "inner" loop then the original code can proceed. – Equidistance