Skip to main content

Swing and event dispatch thread checking

9 replies [Last post]
prunge
Offline
Joined: 2004-05-06
Points: 0

For swing components, when calling a method that should be called only from the event dispatch thread from some other thread, use assertions to indicate an error.

By default, system assertions are disabled which means all code (even the incorrect stuff) would run like normal, but turning them on would point out where any Swing event dispatch thread issues are through their stack traces.

Inside each checked method, the first line would be something like:
assert(SwingUtilities.isEventDispatchThread());

Thinking about annotations, it would be cool if each method that requires running on the event dispatch thread had an annotation like @eventDispatch which would automatically generate the above code through apt. This would also indicate to the user exactly which methods require running on the event dispatch thread and which can be run from other threads through the javadoc. The annotation would also be handy for other Swing component developers. But that might be a bit beyond apt's capabilities for the moment.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
prunge
Offline
Joined: 2004-05-06
Points: 0

Model listeners would catch a large amount of problems. This would catch things like tables updating their data from another thread, setText on text components would catch problems since that would go through the document model. I wonder if property change listeners could be used to advantage here? Are there component properties that can be changed from other threads?

tackline
Offline
Joined: 2003-06-19
Points: 0

It used to be okay to create components outside of the AWT Event Dispatch Thread (EDT) in order to reduce latency. I believe that is no longer recommended. Presumably because javax.swing.text.* is so heavily botched with respect to threading.

yishai
Offline
Joined: 2003-11-16
Points: 0

> Prunge,
>
> > For swing components, when calling a method that
> should be
> > called only from the event dispatch thread from
> some other
> > thread, use assertions to indicate an error.
>
> This is something we've talked about, but we're not
> sure of the scope of what developers want. Do you
> really want it on every public/protected method in
> Swing? That's a HUGE change! Most likely we could
> ignore the plaf classes, but it's still a huge
> change. Would the listeners Swing attaches to models
> be enough?
>
> It could certainly possible to use APT for some of
> this, but we haven't thought it through yet.
>
> -Scott

Besides Zander's excellent suggestion to find the fewest areas where improper access to a Swing object can be detected, I would look at this more from the problem point of view.

Every Swing project of any significant size has to deal with starting new threads, and getting the results back into the event queue. Sun provides a swingworker class, but that isn't quite as transparent as many would like. Given that, what ends up happening is that there are a lot of bugs around updating the GUI outside the eventqueue thread, and it is very hard to track down when that happens. So a combination of a standard Swing api which does the threading right for you, and the easy ability to debug when something goes wrong with the swing threading, would do a lot for the Java Swing programmer's ability to build robust GUIs.

mgrev
Offline
Joined: 2003-08-12
Points: 0

Have you considered a debug version of the JDK for these kind of things? You would still have ONE code base but it could be automatically pre-processed for a normal and a debug version. A lof of checks could then be in the debug version, and the normal could still stay 'lean and mean'..

Cheers,
Mikael Grev

zander
Offline
Joined: 2003-06-13
Points: 0

Hi, Mikael.

Isn't this what assertions were invented for?

mgrev
Offline
Joined: 2003-08-12
Points: 0

Hi, Thomas.

Correct, they are, but if Sun had a more dedicated 'debug' version they would never have to think about these kinds of balancing acts. I.e. 'Should we add it to all or just to some hot spots'. For the debug version the threshhold would be very much lower for entering these kind of things. As well as other checks that may be a little more expensive. The debug version could also have more meaningful (i.e. longer) error messages that collect abit more information. XMLEncoder/Decoder comes to mind..

Assertions are the technology to use for these kinds of thinks for sure, but they still have a slight performance hit even if disabled, and they do increase the code size.

This is nothing I truly want at all costs, but I generally don't like the one-size-fits-all approach we have now.

Cheers,
Mikael Grev

zixle
Offline
Joined: 2004-07-22
Points: 0

Prunge,

> For swing components, when calling a method that should be
> called only from the event dispatch thread from some other
> thread, use assertions to indicate an error.

This is something we've talked about, but we're not sure of the scope of what developers want. Do you really want it on every public/protected method in Swing? That's a HUGE change! Most likely we could ignore the plaf classes, but it's still a huge change. Would the listeners Swing attaches to models be enough?

It could certainly possible to use APT for some of this, but we haven't thought it through yet.

-Scott

zander
Offline
Joined: 2003-06-13
Points: 0

I suggest doing this purely in the layout managers.

I did this (as a System.err) in my layout manager (NaturalLayout) and I find it a great way to find incorrect usages of threading.
I don't think doing it for all methods will cover more cases.

Naturally, not everyone will understand what is going on if a setText on a JLabel is done and triggers an assertion in a layout manager to fail..

yishai
Offline
Joined: 2003-11-16
Points: 0

+1