Swing and the "single thread roule"

[Mihai Radulescu]

A have some problems with this roule.in the theory "swing uses a single thread to deal with UI events".
Ok so... my main thread(application thread) builds the gui and after the gui is ready(that means setVisible(true) I stop(sleep(..)) for one second the current thread(must be the application thread).
After this the gui freeze for one second(you can see this - is no repaint). When the sleeping time is out the thread is runnable again and the gui is ok(repaint is working).
Why ?
My explication is:
The application thread start the gui and end, for this when I stop the current thread ,I stop the swing thread(AWT-EventQueue-0) because this threa is now my "current thread".Because the the swing thread is waiting no events are process -> no repaint(it work with event also).After the time is out the
(AWT-EventQueue-0)thread is runnable -> it is able to deal with events.
Is this right ?
Here is also a pice of code :
private SingleThreadSwing() {
makaAFrame(makeAPanel());
}


private void makaAFrame(JPanel inContentPanel) {
JFrame frame = new JFrame();
frame.getContentPane().add(inContentPanel);
frame.pack();
frame.setVisible(true);
}


private JPanel makeAPanel() {
JPanel panel = new JPanel();
JButton but = new JButton("Sleep");
but.addActionListener(new ActListener());
panel.add(but);
return panel;
}


public static void main(String [] args) {
System.out.println("Thread : " + Thread.currentThread().getName());
new SingleThreadSwing();
}


private class ActListener implements ActionListener {

public void actionPerformed(ActionEvent e) {
System.out.println("Thread : " + Thread.currentThread().getName());
try {
Thread.currentThread().sleep(6000);
} catch (InterruptedException ex) {
ex.printStackTrace();
}
}
}

and the out put is :
Thread : main
Thread : AWT-EventQueue-0
I hope I was right!

[Mogens Nidding]

You are right: The application thread instantiates and initializes the GUI. The event (Swing) thread responds to all events, including clicks on the button.
Actually, what I just wrote should ring some alarm bells: Two threads are accessing the same objects without synchronization! If I remember correctly, though, it shouldn't be a practical problem as long the ONLY things the application thread does is instantiate and initialize the GUI and call pack/setVisible on it, and after that it is only ever touched by the event thread... I haven't got the time to look it up now, but I think I read it in the Java Tech Tips (buried somewhere deep on the java homepage).

[Mogens Nidding]

OK, I think I found the correct Java Tech Tip now: Multithreading in Swing. My previously posted assumption that you will be fine as long as the last thing the application thread ever does to the GUI is call pack seems to be wrong.
Basically, what the tech tip says is that you should always invoke the method that realizes the GUI (pack, show and/or setVisible) from the event thread. The word realizes here means something like "builds native structures for".
Hope this helps!

[Mogens Nidding]

Following a few links, I came across this very interesting note under How to Use Threads in the Swing tutorial:

We used to say that you could create the GUI on the main thread as long as you didn't modify components that had already been realized. [...] While this worked for most applications, in certain situations it could cause problems. [...] To avoid the possibility of thread problems, we recommend that you use invokeLater to create the GUI on the event-dispatching thread for all new applications. [...]

The last two omitted parts soften it up a bit, mentioning that there is very rarely a problem it practise.
Hope this helps even more :-)

[Mihai Radulescu]

ThanX
The "Java Tech Tip" was excellent.