Swing and Threads

E

electric sheep

o.k.

on the sun website they have these cryptic words:
To avoid the possibility of deadlock, you must take extreme care that
Swing components and models are created, modified, and queried only from
the event-dispatching thread.

and they give this sample code:
javax.swing.SwingUtilities.invokeLater(new Runnable() {
public void run() {
createAndShowGUI();
}
});

my question is this.
"create and modify" means just that ... even creating.

i had thought of making a class, having it extend JFrame and implement
Runnable, like so:

class MyGUI extends JFrame implements Runnable {
MyGUI()
...

public void run()
...
}

then do:
javax.swing.SwingUtilities.invokeLater(new MyGUI());

but in fact, that wouldn't be following Sun's advice to the letter i
guess, would it ?

Because the JFrame object (MyGUI) would be created, and then the handle
to this object would be passed to invokeLater().
So in fact, part of the GUI would have already been created in the
"main" thread.

So I guess I need to create my MyGUI object from within a method, say
createGUI(), as opposed to "on-the-fly" like this ?
 
C

Chris Smith

electric said:
on the sun website they have these cryptic words:
To avoid the possibility of deadlock, you must take extreme care that
Swing components and models are created, modified, and queried only from
the event-dispatching thread.

and they give this sample code:
javax.swing.SwingUtilities.invokeLater(new Runnable() {
public void run() {
createAndShowGUI();
}
});

my question is this.
"create and modify" means just that ... even creating.

Yes, apparently so. Initially, the advice from Sun was to avoid
accessing a component from the event dispatch thread after it's
realized. It seems Sun has recently begun advising to do all method
calls on GUI components in the event dispatch thread, however... even if
they do not have peers at the time.

I'm not aware of the precise motivation for this switch (i.e., I don't
know of a test case that fails when non-realized components are accessed
from a non-event thread.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
S

Steve W. Jackson

electric sheep said:
:eek:.k.
:
:eek:n the sun website they have these cryptic words:
:To avoid the possibility of deadlock, you must take extreme care that
:Swing components and models are created, modified, and queried only from
:the event-dispatching thread.
:
:and they give this sample code:
: javax.swing.SwingUtilities.invokeLater(new Runnable() {
: public void run() {
: createAndShowGUI();
: }
: });
:
:my question is this.
:"create and modify" means just that ... even creating.
:
:i had thought of making a class, having it extend JFrame and implement
:Runnable, like so:
:
:class MyGUI extends JFrame implements Runnable {
: MyGUI()
: ...
:
: public void run()
: ...
:}
:
:then do:
:javax.swing.SwingUtilities.invokeLater(new MyGUI());
:
:but in fact, that wouldn't be following Sun's advice to the letter i
:guess, would it ?
:
:Because the JFrame object (MyGUI) would be created, and then the handle
:to this object would be passed to invokeLater().
:So in fact, part of the GUI would have already been created in the
:"main" thread.
:
:So I guess I need to create my MyGUI object from within a method, say
:createGUI(), as opposed to "on-the-fly" like this ?

If Sun's really saying "create and modify" then they're confusing the
issue more than is needed. It's perfectly OK to create GUI components
outside the EDT (as in JPanel panel = new JPanel(), for instance). What
you must not do is cause them to be shown, hidden, added to visible
components, or otherwise have their state changed in a way that would
result in painting and some other actions. So it's just fine to
instantiate your GUI class, but do NOT call pack, or setVisible(true),
or a variety of other things which cause the component hierarchy to be
"realized".

= Steve =
 
C

Christophe Vanfleteren

Steve said:
If Sun's really saying "create and modify" then they're confusing the
issue more than is needed. It's perfectly OK to create GUI components
outside the EDT (as in JPanel panel = new JPanel(), for instance). What
you must not do is cause them to be shown, hidden, added to visible
components, or otherwise have their state changed in a way that would
result in painting and some other actions. So it's just fine to
instantiate your GUI class, but do NOT call pack, or setVisible(true),
or a variety of other things which cause the component hierarchy to be
"realized".

They're saying this for a reason:

read
<http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html>
for the explanation.
 
S

Steve W. Jackson

Christophe Vanfleteren said:
:Steve W. Jackson wrote:
:
:> If Sun's really saying "create and modify" then they're confusing the
:> issue more than is needed. It's perfectly OK to create GUI components
:> outside the EDT (as in JPanel panel = new JPanel(), for instance). What
:> you must not do is cause them to be shown, hidden, added to visible
:> components, or otherwise have their state changed in a way that would
:> result in painting and some other actions. So it's just fine to
:> instantiate your GUI class, but do NOT call pack, or setVisible(true),
:> or a variety of other things which cause the component hierarchy to be
:> "realized".
:
:They're saying this for a reason:
:
:read
:<http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html>
:for the explanation.

I've already read that. And there's nothing in their so-called
explanation that indicates why creating components can be problematic so
long as nothing in the hierarchy has been realized. I have always
adhered to the rule that I build my component hierarchy completely but
never do anything else to it that's not on the EDT -- except once, when
I learned the hard way that I actually had displayed a JWindow on the
main thread.

= Steve =
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top