Why does JDK 1.6 recommend creating Swing components on the EDT?

Discussion in 'Java' started by david.karr, Nov 30, 2009.

  1. david.karr

    david.karr Guest

    When I first did Swing work several years ago, it was well known that
    after Swing components were "realized", all access to them had to be
    done on the Event Dispatch Thread. That means that ordinary assembly
    of the required components, before they are shown, didn't have to
    happen on the EDT.

    It appears that the recommendations in JDK 1.6 have changed this. At
    <http://java.sun.com/javase/6/docs/api/javax/swing/package-
    summary.html>, in the "Swing's Threading Policy" section, it concludes
    that ALL access to Swing components, even construction, has to be on
    the EDT. This seems odd. Besides the statements at that javadoc
    page, is there any justification for this change in strategy? Is
    there really code now that executes in the constructor of a Swing
    component that needs to execute on the EDT?
    david.karr, Nov 30, 2009
    #1
    1. Advertising

  2. david.karr

    Lew Guest

    Peter Duniho wrote:
    > There may be some specific change that has led to the difference you're
    > seeing in the documentation (though frankly, I'm not sure this
    > recommendation really is new to 1.6), but I think it's more likely that
    > it's just that prior advice was flawed.  That it's always been the case
    > that you can't be assured that just because code is in the constructor
    > of a Swing component (or even simply code executed before some explicit
    > realization of the component, such as showing it), it's safe to execute
    > that code outside of the EDT, and that the current documentation is
    > simply fixing that oversight in past documentation.
    >


    That's exactly what Sun tells us - that they were mistaken when they
    thought you could construct GUI components off the EDT. The advice to
    put all GUI action on the EDT both prior to and after realization is
    retroactive to all versions of Swing.

    For the current wisdom, here are a couple of links:
    <http://java.sun.com/docs/books/tutorial/uiswing/concurrency/
    dispatch.html>
    which contains an informative link to
    <http://weblogs.java.net/blog/kgh/archive/2004/10/
    multithreaded_t.html>

    <http://java.sun.com/developer/JDCTechTips/2005/tt0419.html#1>

    --
    Lew
    Lew, Nov 30, 2009
    #2
    1. Advertising

  3. david.karr

    markspace Guest

    david.karr wrote:

    > It appears that the recommendations in JDK 1.6 have changed this. At
    > <http://java.sun.com/javase/6/docs/api/javax/swing/package-
    > summary.html>, in the "Swing's Threading Policy" section, it concludes
    > that ALL access to Swing components, even construction, has to be on
    > the EDT.



    Yeah, Sun fuggered up their earlier recommendation and had to take it
    back. Everything goes on the EDT now.

    I think this may have had something to do with the new memory model in
    1.5 when they really sussed all this stuff out and went "whoopsie" but
    I'm just speculating there.

    Besides actual thread safety and associated issues like visibility and
    synchronization, there's I think a software issue. Swing components
    often have "listeners" of some type, and these listeners are designed to
    execute on the EDT.

    Since these listeners are asynchronous and respond to events (like
    property changes) it's possible to have these listeners fire as you
    construct your GUI. The result is that some listeners are being
    executed on the EDT as you are constructing in your main thread, and
    some listeners might be running on some other thread as well (because
    the listener is confused and fires on the wrong thread). The result is
    a huge unpredictable mess.

    The EDT synchronizes these issues because it doesn't allow any listeners
    to run while it's busy doing something else. It's just one thread, it
    can't, so the listeners are queued up and executed later, which is just
    what you want.
    markspace, Nov 30, 2009
    #3
  4. david.karr

    Roedy Green Guest

    On Mon, 30 Nov 2009 13:39:07 -0800, markspace <>
    wrote, quoted or indirectly quoted someone who said :

    >Yeah, Sun fuggered up their earlier recommendation and had to take it
    >back. Everything goes on the EDT now.


    The problem is threading bugs are very hard to reproduce and track
    down. My putting everything onto the EDT thread, they avoid a large
    number of headaches.
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com
    I mean the word proof not in the sense of the lawyers, who set two half proofs equal to a whole one, but in the sense of a mathematician, where half proof = 0, and it is demanded for proof that every doubt becomes impossible.
    ~ Carl Friedrich Gauss
    Roedy Green, Dec 1, 2009
    #4
  5. david.karr

    Albert Guest

    Le 01/12/2009 09:54, Roedy Green a écrit :
    > On Mon, 30 Nov 2009 13:39:07 -0800, markspace<>
    > wrote, quoted or indirectly quoted someone who said :
    >
    >> Yeah, Sun fuggered up their earlier recommendation and had to take it
    >> back. Everything goes on the EDT now.

    >
    > The problem is threading bugs are very hard to reproduce and track
    > down. My putting everything onto the EDT thread, they avoid a large
    > number of headaches.


    have you actually seen such a bug ? Something like corrupted data in a
    swing model for example ? I've never triggered such a bug, even if i did
    a lot of gui calls off the EDT.
    Albert, Dec 1, 2009
    #5
  6. david.karr

    Lew Guest

    Roedy Green a écrit :
    >> On Mon, 30 Nov 2009 13:39:07 -0800, markspace<>
    >> wrote, quoted or indirectly quoted someone who said :
    >>
    >>> Yeah, Sun fuggered up their earlier recommendation and had to take it
    >>> back. Everything goes on the EDT now.

    >>
    >> The problem is threading bugs are very hard to reproduce and track
    >> down. My putting everything onto the EDT thread, they avoid a large
    >> number of headaches.


    Albert wrote:
    > have you actually seen such a bug ? Something like corrupted data in a
    > swing model for example ? I've never triggered such a bug, even if i [sic] did
    > a lot of gui calls off the EDT.


    I've never actually seen Roedy but I know he exists.

    Have you tried running improperly-threaded Swing programs on a multiprocessor
    machine? Millions of times?

    It took Sun, with its knowledge of millions of Java programs and some of the
    very best minds in the computer world working on Java, years to figure out
    that their earlier advice regarding Swing and the EDT was wrong. That's why
    the OP thought maybe that the new advice was specific to the latest version of
    Java when it actually applies to all versions of Swing. .Net has the same
    advice.

    This is why professional computer programmers read a lot. We know that our
    own personal experience is limited so we seek out the wider experience of the
    community at large and follow industry best practices. We would rather learn
    from others' wisdom than have an expensive, embarrassing and entirely
    avoidable problem at the customer site.

    "But that never happened to me before!" will be small comfort then.

    --
    Lew
    Lew, Dec 1, 2009
    #6
  7. In article <4b14e2a7$0$968$>,
    Albert <> wrote:

    > Le 01/12/2009 09:54, Roedy Green a écrit :
    > > On Mon, 30 Nov 2009 13:39:07 -0800, markspace<>
    > > wrote, quoted or indirectly quoted someone who said :
    > >
    > >> Yeah, Sun fuggered up their earlier recommendation and had to take
    > >> it back. Everything goes on the EDT now.

    > >
    > > The problem is threading bugs are very hard to reproduce and track
    > > down. y putting everything onto the EDT thread, they avoid a
    > > large number of headaches.

    >
    > have you actually seen such a bug ? Something like corrupted data in
    > a swing model for example ? I've never triggered such a bug, even if
    > i did a lot of gui calls off the EDT.


    As an erstwhile apostate, I have to say yes, twice:

    1) On a slow, dual-core machine, while creating a JTree with a complex
    selection listener, but not on a comparable single-core machine.

    2) On a fast machine with a poorly chosen value for the initial delay of
    a timer, and then only once in a while.

    As others have noted, the problems may me hardware dependent.

    --
    John B. Matthews
    trashgod at gmail dot com
    <http://sites.google.com/site/drjohnbmatthews>
    John B. Matthews, Dec 1, 2009
    #7
  8. david.karr

    Roedy Green Guest

    On Tue, 01 Dec 2009 10:32:24 +0100, Albert <> wrote,
    quoted or indirectly quoted someone who said :

    >
    >have you actually seen such a bug ? Something like corrupted data in a
    >swing model for example ? I've never triggered such a bug, even if i did
    >a lot of gui calls off the EDT.


    I vaguely recall reading about freezing bugs when you did not use the
    EDT thread. They trickled out. I think Sun decided to put out this
    warning, since presumably there were still more bugs not yet
    discovered. This was a way of avoiding them.

    You could have a look in the bug parade.

    see http://mindprod.com/jgloss/bugs.html


    --
    Roedy Green Canadian Mind Products
    http://mindprod.com
    I mean the word proof not in the sense of the lawyers, who set two half proofs equal to a whole one, but in the sense of a mathematician, where half proof = 0, and it is demanded for proof that every doubt becomes impossible.
    ~ Carl Friedrich Gauss
    Roedy Green, Dec 1, 2009
    #8
  9. david.karr

    Guest

    On Nov 30, 7:59 pm, "david.karr" <> wrote:
    ....
    > It appears that the recommendations in JDK 1.6 have changed this.


    Yup...

    I came to the realization that Swing was thread hostile. I now
    do everything on the EDT and things are fine (well, as fine as
    they can be with Sun / Swing's poor perfs... Latest joke upon
    me was the hooplas I had to go true to get reasonable memory/CPU
    usage using 'advanced' JTables. Thankfully I found Sun's
    "Christmas tree" doc and while I was reading it I kept thinking
    "wtf, this is a client app running mostly on Core 2 Duos, doing
    billions of cycles per second, and painting a f***ing JTable is
    *that* slow!?").

    I hugely suggest using the ThreadCheckingRepaintManager:

    https://swinghelper.dev.java.net/
    , Dec 2, 2009
    #9
  10. david.karr

    Nigel Wade Guest

    Re: Why does JDK 1.6 recommend creating Swing components on theEDT?

    On Tue, 01 Dec 2009 10:32:24 +0100, Albert wrote:

    > Le 01/12/2009 09:54, Roedy Green a écrit :
    >> On Mon, 30 Nov 2009 13:39:07 -0800, markspace<>
    >> wrote, quoted or indirectly quoted someone who said :
    >>
    >>> Yeah, Sun fuggered up their earlier recommendation and had to take it
    >>> back. Everything goes on the EDT now.

    >>
    >> The problem is threading bugs are very hard to reproduce and track
    >> down. My putting everything onto the EDT thread, they avoid a large
    >> number of headaches.

    >
    > have you actually seen such a bug ? Something like corrupted data in a
    > swing model for example ? I've never triggered such a bug, even if i did
    > a lot of gui calls off the EDT.


    Yes, I have encountered such a bug. Just because you've never actually
    experienced the problem does not mean that the problem does not exist, or
    that it's safe to ignore it. You can never know when the bug will strike,
    and this makes them almost impossible to track down. The symptoms vary,
    as do their timing. It may run perfectly 99 times out of a 100. Or it may
    work perfectly every time on one system, but fail on another.

    In my case the GUI worked perfectly - most of the time. But every once in
    a while some of the components were not drawn correctly when the GUI
    first appeared. The components which were not fully drawn varied.

    At that time the recommendation from Sun, as explained in the Java Swing
    Tutorial, was that it was safe to create the GUI on the main thread until
    such time as the first component was realized, when the EDT would be
    started. From this point on (once the EDT was running) all subsequent use
    of any Swing component should be done on the EDT. It was around the same
    time as I was having my problem that Sun changed their advice on this
    issue (and also updated the Tutorial - this was the 1.4/1.5 Tutorial,
    prior to the re-write for 1.6). So I altered my code to follow their
    advice and the problem went away, never to be seen again.

    IIRC, Sun explained this by saying that certain components may, during
    construction, perform operations which caused the EDT to be started even
    though they had not yet been realized. Rather than working through the
    source code for every single component to check what operations its
    constructor performed and whether they started the EDT (and updating the
    Javadocs accordingly), it was simpler just to advise that all components
    should be constructed on the EDT.

    --
    Nigel Wade
    Nigel Wade, Dec 7, 2009
    #10
    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. Thomas G. Marshall
    Replies:
    5
    Views:
    785
    Thomas G. Marshall
    Aug 6, 2004
  2. mkrause
    Replies:
    0
    Views:
    661
    mkrause
    May 6, 2005
  3. Scott Abel
    Replies:
    0
    Views:
    422
    Scott Abel
    Sep 6, 2005
  4. Scott Abel
    Replies:
    0
    Views:
    435
    Scott Abel
    Sep 27, 2005
  5. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,748
    Smokey Grindel
    Dec 2, 2006
Loading...

Share This Page