
Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.
> Newbies often bring problems to the table that suggest they have done
> something to tie up the swing thread either by giving it some lengthy
[quoted text clipped - 3 lines]
> well any GUI app that can detect that, and perhaps even diagnose where
> it is happening.
Ctrl-\ in the terminal window (or Ctrl-Break is it on the other platform?).
> 2. this one is more difficult. People often poke Swing components
> from the non Swing thread. How could you create a wrapper around all
> the Swing components to detect that abuse in a way even a newbie
> could use it? Perhaps there is a way using the JXTA debug interface
> to pull it off in Java.
There's the quite cunning ThreadCheckingRepaintManager that checks
repaint events are from the EDT. The theory being that virtually
anything you do to a component causes a repaint. Probably wouldn't have
got the setCursor problem that hanged JEdit on 1.5. Perhaps a more
comprehensive method would be to check all calls through peer interfaces.
http://www.clientjava.com/blog/2004/08/31/1093972473000.html
I doubt if bytecode injection would catch many more bugs.
There's an interesting bug in the Bug Parade. Apparently AWT was found
to have 2486 potential deadlocks, using JMTA. Perhaps something similar
could be done for race conditions (which Swing has a number of).
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6231322
http://sourceforge.net/projects/jmta/
Tom Hawtin

Signature
Unemployed English Java programmer
http://jroller.com/page/tackline/
Roedy Green - 30 Sep 2005 20:01 GMT
>There's the quite cunning ThreadCheckingRepaintManager that checks
>repaint events are from the EDT. The theory being that virtually
[quoted text clipped - 12 lines]
>http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6231322
>http://sourceforge.net/projects/jmta/
That was a fascinating post. I have added material and links at
http://mindprod.com/jgloss/thread.html#DEBUGGING
based on your post for future reference.

Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.
Roedy Green - 30 Sep 2005 20:15 GMT
>There's an interesting bug in the Bug Parade. Apparently AWT was found
>to have 2486 potential deadlocks, using JMTA. Perhaps something similar
>could be done for race conditions (which Swing has a number of).
>
>http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6231322
After reading that I began to wonder if we are all wet on the way
handle locks. Perhaps the way they should work is you have to get all
your desired locks together and ask for them ALL at ONCE. Then the
locks themselves have a unique internal priority that define the order
you have to grab them. Attempting to grab a set automatically
releases everything you already have.
That would introduce a basketful of other problems, but perhaps things
might work that way within lock groups.
Another idea is locks within groups have priority numbers. You can't
grab a lock within a group with priority higher than you have already,
at least in assertions on mode.

Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.
> Newbies often bring problems to the table that suggest they have done
> something to tie up the swing thread either by giving it some lengthy
[quoted text clipped - 9 lines]
> could use it? Perhaps there is a way using the JXTA debug interface
> to pull it off in Java.
This is one of the few places where AOP sounds interesting. AOP could
be used to solve SOME of #1 (intercept uses of certain blocking APIs
from the EDT) and pretty much all of #2 (intercept calls to Swing
components outside of the EDT) at runtime. Of course, building the
rules for #2 could be tedious, as you'd need to go through all of Swing
and determine the rules for when it is/isn't safe to access something
through a non-EDT thread.

Signature
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
Roedy Green - 30 Sep 2005 20:18 GMT
> Of course, building the
>rules for #2 could be tedious, as you'd need to go through all of Swing
>and determine the rules for when it is/isn't safe to access something
>through a non-EDT thread.
I have a list of the methods are supposed to be safe according to
notes from Sun I found in various places. See
http://mindprod.com/jgloss/threadsafe.html
It is not very long. The list becomes a sort of contract. You don't
want people looking at code to find out what IS safe and then trusting
the code to stay that way forever. You might do that, and hand the
list to Sun to see if they are willing to make a commitment to keeping
some of those methods safe.
That simplifies your task of classifying methods.

Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.