Re: Help! Swing & Threads
Mark Space wrote:
I have a question which is weirding me out and I can't find any answers to.
Basically, Swing makes a special thread to invoke various Swing events
such as ActionEvents, yes?
So what happens when you of your listeners invokes a long action, or
blocks? Doesn't the rest of the Swing components have to stop until
that listener unblocks? It wouldn't be safe for Java to just make a new
thread and call some more events...
Yes: If you perform some long-winded procedure while
executing on the event-dispatching thread, no further events
will be dispatched until your procedure is finished. Scroll
bars won't scroll, buttons won't butt, and windows won't
respond to size changes -- your GUI will seem to be frozen.
Ok, but I see a lot of examples where a menu item, File->Open for
example, invokes JFileChooser which does indeed block. (For example,
O'Reilly's Learning Java does this in it's example for the
JFileChooser.) What the heck is going on here?
JFileChooser doesn't block, or at any rate not for very
long (assuming the file system itself doesn't block for very
long). It reads some state (the contents of a directory) from
the file system, formats it for display, and returns -- at which
point the event-dispatching thread goes back to keeping the GUI
un-gluey. When the user twiddles one of the JFileChooser's
control doodads, the event-dispatching thread calls one of the
JFileChooser's event handlers; the JFileChooser responds by
scrolling the view or switching to a different directory or
whatever, updates its display accordingly, and once again returns
to the event-dispatching thread. The JFileChooser, like any good
GUI element, does not tie up the computer when there's nothing to
be done: It saves enough state to maintain awareness of what's
going on, returns to the event-dispatcher thread, and awaits
developments.
I guess my question really is serveral questions:
1. Is invoking from a listener JFileChooser safe?
Yes.
2. Should I be spawning my on thread instead?
Not unless you have reason to believe the I/O operations
themselves will take inordinate amounts of time. If you're
using a custom JFileChooser subclass that browses a library
of archive tapes managed by a slow robot or if you're browsing
directories of a million entries each then it might make sense
to do something special, but for simple "list the contents"
queries on ordinary directories ... Naah.
3. Does Swing do anything fancy or special with JFileChooser to prevent
deadlocks when the listener thread blocks?
Nothing special, really: JFileChooser just behaves like any
other state-preserving event-driven GUI object. Do you think a
JButton does something special while waiting to be pressed?
Try this experiment: Write yourself a little GUI that fires
up *two* JFileChoosers simultaneously, and browse through a
couple different parts of your disk in side-by-side choosers.
The experiment itself won't teach you much, but pondering what's
going on might.
4. What the best general case solution for "long tasks" inside listeners?
Run them in a separate thread that reports back asynchronously.
You can launch the thread directly from the listener, or you can
have the thread sitting ready until the listener puts something on
it's "To Be Done" queue, or ... The main thing is to let the event
dispatcher get back to the business of dispatching events.
5. Is there a good source for questions like this one? Most of the
tutorials seem very simplified.
Personally, I found the material in the Java Tutorial adequate.
Their Swing chapter includes a section specifically devoted to
threading, and I found it enough to get started with. YMMV.
Thanks for your help, this really bugging me and I can't find detailed
answers anywhere.
No, no: "This" isn't bugging you; "The NSA" is bugging you.
--
Eric Sosman
esosman@acm-dot-org.invalid