Swing and Threads

Discussion in 'Java' started by electric sheep, May 19, 2004.

  1. 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 ?
     
    electric sheep, May 19, 2004
    #1
    1. Advertising

  2. electric sheep

    Chris Smith Guest

    electric sheep wrote:
    > 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
     
    Chris Smith, May 19, 2004
    #2
    1. Advertising

  3. In article <eJOqc.4845372$>,
    electric sheep <> wrote:

    >: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 =
    --
    Steve W. Jackson
    Montgomery, Alabama
     
    Steve W. Jackson, May 19, 2004
    #3
  4. 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.

    --
    Kind regards,
    Christophe Vanfleteren
     
    Christophe Vanfleteren, May 19, 2004
    #4
  5. In article <grQqc.118044$-ops.be>,
    Christophe Vanfleteren <> wrote:

    >: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 =
    --
    Steve W. Jackson
    Montgomery, Alabama
     
    Steve W. Jackson, May 19, 2004
    #5
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Big Daddy

    Java 1.2 Swing vs. Java 1.5 Swing

    Big Daddy, Apr 15, 2005, in forum: Java
    Replies:
    2
    Views:
    501
    Pete Barrett
    Apr 16, 2005
  2. mkrause
    Replies:
    0
    Views:
    674
    mkrause
    May 6, 2005
  3. lizard
    Replies:
    0
    Views:
    1,770
    lizard
    Jan 30, 2006
  4. S.T
    Replies:
    2
    Views:
    582
  5. Knute Johnson

    Swing is dead! Long live Swing.

    Knute Johnson, Feb 16, 2012, in forum: Java
    Replies:
    32
    Views:
    3,771
    Daniel Pitts
    Feb 29, 2012
Loading...

Share This Page