Swing/Thread ShortCut - Bad Style or Good Idea?

[Hal Vaughan]

I tend to have trouble remembering little things and have to keep looking
them up, especially when they involve things like repeated symbols, like
creating a new thread and remembering to keep the {} () groupings straight
(it's actually part of a learning disability).

One thing that gets to me about Swing is that if a component triggers more
of an action than just setting a variable, the UI won't update until it's
done unless I use separate threads. When I write a panel for a GUI, I tend
to dispatch all the functions from within that panel with only one
actionPerformed() method. That means I have a lot of IF statements in that
one method.

It's occurred to me that if I have 8 components on a panel and 3-5 of them
trigger lengthy actions, I might as well just do something like this:

public void actionPerformed(ActionEvent aEvent) {
new Thread(
new Runnable() {
public void run() {
//eventSource is defined in the class, but not in the method
eventSource = aEvent.getSource();
if (eventSource == jButton1) {
//do stuff
}
if (eventSource == jButton2) {
//do stuff
}
...
}
}
).start();
return;
}

In other words, just start a new thread in the actionPerformed() method so
anything done will be in a separate thread so the event dispatching thread
will be able to update the UI no matter what.

Is this a good shortcut or a bad idea because of other consequences that I
may not be aware of? Is it something that could be done depending on what
the other methods it calls do?

Thanks for any comments. I'm trying to understand Swing and threads, which
I've had trouble with along the way.

Hal

 

[Mark Space]

Is this a good shortcut or a bad idea because of other consequences that I
may not be aware of? Is it something that could be done depending on what
the other methods it calls do?

Yes, it depends very much on what methods you invoke.

First, realize that Swing uses threads to synchronize shared objects.
That is, if you modify any Swing component, you must do so on the EDT
thread or you will get weird, hard to debug error appearing
intermittently in your code.

There are a few methods which are safe to call from threads other than
the EDT. repaint(), invalidate(), and revalidate() all come to mind.
Also, setText() for the JText objects can be called safely anywhere.
Check the documentation carefully. If a method is not noted as being
thread safe, it ain't.

Finally, synchronization is pretty easy. Just call
java.awt.EventQueue.invokeAndWait() with another Runnable from with in
your worker thread and you'll be all synchronized. There's also
invokeLater(), but invokeAndWait is likely to be a bit easier to
understand because it's synchronous.

With all that out of the way, yes it's a very good idea to have long
running tasks run on threads outside the EDT, just like you've shown.
Best idea since the Jacquard loom.

I don't however like the idea of testing for which buttons invoked the
event, from inside your thread. It smacks of maintenance issues.
Better to make a simple method that doesn't know anything about GUIs or
buttons or text areas or anything, and just call that directly from one
action listener. Simpler this way in the long run, even if it's more
typing.

OK, my 2 nickels. And I still want to know if that code for
non-focusable windows works in your environment too. ^_^