Search code examples
javaswingawtevent-dispatch-thread

must all methods in AWT classes, i.e. non-Swing ones, be called in the EDT?

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

Solution

  • 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.