Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Why does JDK 1.6 recommend creating Swing components on the EDT?

Reply
Thread Tools

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

 
 
david.karr
Guest
Posts: n/a
 
      11-30-2009
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/ap...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?
 
Reply With Quote
 
 
 
 
Lew
Guest
Posts: n/a
 
      11-30-2009
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/tutor...g/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
 
Reply With Quote
 
 
 
 
markspace
Guest
Posts: n/a
 
      11-30-2009
david.karr wrote:

> It appears that the recommendations in JDK 1.6 have changed this. At
> <http://java.sun.com/javase/6/docs/ap...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.
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      12-01-2009
On Mon, 30 Nov 2009 13:39:07 -0800, markspace <(E-Mail Removed)>
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
 
Reply With Quote
 
Albert
Guest
Posts: n/a
 
      12-01-2009
Le 01/12/2009 09:54, Roedy Green a ťcrit :
> On Mon, 30 Nov 2009 13:39:07 -0800, markspace<(E-Mail Removed)>
> 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.
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      12-01-2009
Roedy Green a écrit :
>> On Mon, 30 Nov 2009 13:39:07 -0800, markspace<(E-Mail Removed)>
>> 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
 
Reply With Quote
 
John B. Matthews
Guest
Posts: n/a
 
      12-01-2009
In article <4b14e2a7$0$968$(E-Mail Removed)>,
Albert <(E-Mail Removed)> wrote:

> Le 01/12/2009 09:54, Roedy Green a écrit :
> > On Mon, 30 Nov 2009 13:39:07 -0800, markspace<(E-Mail Removed)>
> > 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. [B]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>
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      12-01-2009
On Tue, 01 Dec 2009 10:32:24 +0100, Albert <(E-Mail Removed)> 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
 
Reply With Quote
 
alexandre_paterson@yahoo.fr
Guest
Posts: n/a
 
      12-02-2009
On Nov 30, 7:59 pm, "david.karr" <(E-Mail Removed)> 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/


 
Reply With Quote
 
Nigel Wade
Guest
Posts: n/a
 
      12-07-2009
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<(E-Mail Removed)>
>> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Why not using javax.swing.event with swing? S.T Java 2 05-25-2007 12:10 AM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
Swing Model Classes Updating Swing Components on a Thread Other Than AWT mkrause Java 0 05-06-2005 04:32 PM
jEdit: compiles JDK 1.5.0 ok, but runs JDK 1.4.1 (why?) Thomas G. Marshall Java 5 08-06-2004 04:12 AM
SWING components adjustment in different resolutions - Should show scrollbars less than 800X600 and expand components over this resolution Bluetears76 Java 1 07-01-2004 09:01 PM



Advertisments