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?

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.