1

I recently learnt that Sun's/Oracle's most recent guidelines say that no Swing methods of any Swing objects, including constructors, must be called outside the EDT.

Does the same standard of rigour apply to all "visual" AWT classes too? If not, what ** are ** the rules for them?

later

re Swing and EDT: discussion from 2009.

http://www.velocityreviews.com/forums/t707173-why-does-jdk-1-6-recommend-creating-swing-components-on-the-edt.html

quote: "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."

maybe they don't know what they're talking about... but at the moment I'm taking a "better safe than sorry" approach. Also Potochkin, at http://weblogs.java.net/blog/alexfromsun/archive/2006/02/debugging_swing.html seems to take it as read that we are familiar with the later, stricter rules

Zoyd
  • 3,449
  • 1
  • 18
  • 27
mike rodent
  • 14,126
  • 11
  • 103
  • 157
  • Your original statement, that *all* Swing methods must be called on the EDT is incorrect. There are some thread-safe methods that may be called off of the EDT, such as `repaint()`, and this is well documented in the Java API. I don't do AWT coding, but I would imagine that the documentation on this would be similar. – Hovercraft Full Of Eels Sep 14 '12 at 13:56
  • Please see [this article](http://java.sun.com/products/jfc/tsc/articles/threads/threads1.html) for the details on this. Also, why use AWT at all rather than Swing, or is this question for academic purposes only? – Hovercraft Full Of Eels Sep 14 '12 at 14:05
  • perhaps you might like to look at this SO question... http://stackoverflow.com/questions/11072423/how-does-a-jtree-respond-to-a-changed-defaultmutabletreenode ... which led me to this page: http://weblogs.java.net/blog/alexfromsun/archive/2006/02/debugging_swing.html ... This appears to date from 2006 or later, whereas the page you showed seems to be from 2000. I now have the impression that all Swing methods must be done in the EDT. Also, I checked Component.repaint() in my API... no mention of it being able to be called off the EDT... – mike rodent Sep 14 '12 at 14:11
  • @Hovercraft, "must" is a strong statement. Makes it sound like they can't be called off the EDT. I agree, why use AWT? AWT is more limited that Swing. – km1 Sep 14 '12 at 14:13
  • why AWT? Good question. I am just now rewriting stuff on the basis that all Swing calls must be done in the EDT... if AWT is slightly more permissive this might be of use for some simple GUI purposes... – mike rodent Sep 14 '12 at 14:17
  • Edit: Comment deleted and changed into an answer. – Hovercraft Full Of Eels Sep 14 '12 at 14:19

2 Answers2

5

Correct synchronization in a multi-threaded Java program hinges on the happens-before relation, summarized in Memory Consistency Properties. AWT Components were intended to be thread safe, synchronizing on a private lock object in java.awt.Component. See the comments for some historical perspective:

private transient Object objectLock = new Object();

While this may prove sufficient for simple programs, more complex programs are required to rely on knowledge of this implementation detail to verify correct synchronization. It's possible, but who wants to settle for a brittle AWT GUI?

Some additional points:

  • The article cited by @Hovercraft dates to 1998, but it has been updated repeatedly to address such issues as the new memory model mentioned in the usenet thread you cited.

  • The evolution of javax.swing has been away from GUI API promises, as mentioned here, and toward more flexible concurrent programming tools.

Community
  • 1
  • 1
trashgod
  • 203,806
  • 29
  • 246
  • 1,045
  • thanks... on the Potochkin page http://weblogs.java.net/blog/alexfromsun/archive/2006/02/debugging_swing.html he specifically says "Initially there was a rule that it is safe to create and use Swing components until they are realized but this rule is not valid any more, and now it is recommended to interact with Swing from EDT only" - unfortunately with a broken link at the end of this assertion. Care to comment? – mike rodent Sep 15 '12 at 07:16
  • I'm not sure when it was migrated, but I've been citing related pages from [here](http://docs.oracle.com/javase/tutorial/uiswing/concurrency/index.html) for several years. – trashgod Sep 15 '12 at 22:16
  • I don't follow: you're not sure when what was migrated? Thing is, Potochkin is a senior Sun person (now Oracle, or has he left?) whose speciality seems to be Swing. This comment of yours actually directs to a Swing tutorial guide principally about SwingWorker, and does not answer either the question about AWT or about EDT-confinement for Swing... – mike rodent Sep 18 '12 at 21:41
  • I'm not sure when the EDT advice was migrated. I know nothing of Potochkin except articles such as the one you cited. The article cited in my comment is only the first page of a trail on the topic. All supported platforms require single threaded access to peer components. Using AWT won't _eliminate_ concurrency overhead; it will merely _obscure_ it. – trashgod Sep 18 '12 at 23:34
4

You state:

why AWT? Good question. I am just now rewriting stuff on the basis that all Swing calls must be done in the EDT... if AWT is slightly more permissive this might be of use for some simple GUI purposes...

My reply:
That's bad reasoning. Swing is so much more powerful and flexible that it would be like breaking a puppy's legs before buying it just so you wouldn't have to walk it. Use Swing, follow the threading rules which are hardly likely to be more onerous than AWT, and enjoy. The threading rules make sense and are not hard to follow. Again, this article is a great reference for this.

Hovercraft Full Of Eels
  • 283,665
  • 25
  • 256
  • 373
  • thanks... am familiar with power of Swing. Your article is way old, it appears (2000). If you can be bothered to follow up the links I've given might be helpful... – mike rodent Sep 14 '12 at 14:30
  • @mike: thanks for the links, and you are correct, the rules are more stringent, but again they are hardly complex or difficult. I have tried Googling regarding AWT and can find little on this, likely because there really is much less written about AWT within the past 10 years since Swing has eclipsed it. I still stand by my advice. – Hovercraft Full Of Eels Sep 14 '12 at 14:33
  • you stand by your advice... regarding what? You see what might actually be quite helpful would be for you to say: ah, interesting, the rules re Swing are now more strict... this page here (www.xxx) is the definitive set of rules for Java 6+. I am assuming for the mo that the only thing allowed in a non-EDT is JOptionPane's static showXXX methods... – mike rodent Sep 18 '12 at 21:44
  • @mikerodent: no, even JOptionPane's static showXXX methods *should* be called on the event thread. – Hovercraft Full Of Eels Sep 18 '12 at 22:51
  • @hovercraft you appear to be right... since 2004 rule changes. But then this possibly makes them crap because the ideas is that they block their calling thread ... and even a modal dialog must allow the "pulse of the EDT" to continue to beat. Unless of course calling them in the EDT causes another "Event Dispatch Pump" to crank up... hmm. Needs looking into... Thanks for pointing this out. – mike rodent Sep 21 '12 at 13:07