Re: invokeLater and weird race conditions in my swing app
Nigel Wade wrote:
The EDT is started by the JVM when you realize the first GUI component. From
this time forward all modifications to the GUI should be handled by the EDT.
Actually, even before this point one should only do GUI on the EDT. That
"after it's realized" rule turned out to be unsafe.
See
<http://www.javaworld.com/javaworld/jw-08-2007/jw-08-swingthreading.html>
page 3.
Using SwingUtilities.invokeLater() is one way of doing this. [There are a few
exceptions in that you are allowed to invoke some methods of some components
from other threads, but it's simplest if you treat all methods of all Swing
components as non thread-safe.] I think the reason Swing does this is that if
the components were made thread safe by internal locking the GUI interface
might well respond too slowly. So they are not locked, and the single-thread
rule must be obeyed.
That's not the reason. Swing is single-threaded because the designers found
that it's infeasible to write a multi-threaded GUI API.
IIRC X/Motif is (or at least it was) inherently single-threaded. I have some
That's true. It's cited (amongst others) in the articles that explain why
Swing is single-threaded.
If you are using Java 1.6 then look at the SwingWorker class. This ought to be
able to do what you require. Also, read the tutorial on "Creating a GUI with
JFC/Swing" at http://java.sun.com/docs/books/tutorial/uiswing/TOC.html, in
particular the section on How to Use Tables. This could provide you with some
valuable assistance.
From Java 1.2 through 5, use java.awt.EventQueue.invokeLater() and its kin.
<http://java.sun.com/javase/6/docs/api/java/awt/EventQueue.html#invokeLater(java.lang.Runnable)>
It's tricky to get this right even so. /Java Concurrency in Practice/ by
Goetz, et al., has good material on it. The Swing chapter (Chapter 9) is
available on line as a sample chapter, I believe.
SwingWorker is a beautiful solution.
--
Lew