How careful do you need to be with SwingUtilities.invokeLater()

Question

Is it safe to call an SwingUtilities.invokeLater() from within a method that was invoked with SwingUtilites.invokeLater() ?
I'll give a quick example below.
    public void setWindowLocation(final Point p) {
        //Throw this on to the ETD with a recursive method call.
        if(!SwingUtilities.isEventDispatchThread()){
            SwingUtilities.invokeLater(new Runnable(){
                public void run() {
                    setWindowLocation(p);
            //don't execute recursive call twice.
            return;
        }// end - EDT section.
        assert EventQueue.isDispatchThread():"Not Event Dispatch Thread";
        frame.setLocation(p);
        someOtherMethodThatCallsInvokeLater();
public void someOtherMethodThatCallsInvokeLater(){
      //be lazy don't bother to check if already on event dispatch thread.
       Runnable update = new Runnable(){
            public void run(){
                remoteModeWindow.setTransparency(50);
        SwingUtilities.invokeLater(update);
}What would happen would when the second method is called that didn't bother to see if it was already on the Event Dispatch thread, and just called invokeLater() anyway. Is that harmless, or can it lead to deadlock, or some other inefficiency?
The reason I ask, is I've seen some code in one class check and some in a different class that previously was only called from a non-dispatch thread never bothered to check. It is now possible that the "don't bother to check" method could be called in either situation (i.e. from a dispatch thread, or non-dispatch thread).
Comments appreciated. What is a general guideline for this situation? Too many of the Swing books I've seen only lightly cover a few pages on this topic.
Edited by: asnyder on Jul 2, 2009 7:14 PM

Answer 1

Calling invokeLater(...) in this manner is absolutely safe with regards to deadlocks. What happens is that your runnable is enqueued at the end of the event queue. There is a possibility that another runnable has been dispatched in the mean time, so there is no guarantee that your code will be executed immediately:
1. EDT enters someOtherMethodThatCallsInvokeLater()
2. Another event (from another thread) triggers a repaint for a component or some other UI operation, which is enqueued
3. Your runnable is enqueued on the EDT
So highly theoretically there may be a delay which could be avoided if you immediately executed the runnable:
public void someOtherMethodThatCallsInvokeLater(){
       Runnable update = new Runnable(){
            public void run(){
                remoteModeWindow.setTransparency(50);
        if (SwingUtilities.isEventDispatchThread())
            update.run();
        else
            SwingUtilities.invokeLater(update);
}In my experience though this kind of 'optimization' has no practical implications whatsoever.