Using invokeLater() will still result in the code being executed on the
event thread since that is how it works.  I guess what you need to worry
about is someone starting a different thread and doing the setText from
that. Of course, doing so would be a bug and then the question comes
down to how much code should you write to shield yourself from bugs.

Although I seldom do it, I might agree with making a call to a method
that checks if it is the event thread and log an error if not.  I
probably would not go so far as to create a Runnable and use
invokeLater() to ensure my properyChange code executes on the event thread.

This is a problem for all possible events that can be fired by a
component. Property changes might just be the most obvious ones. Event
listeners are nothing but callback methods, and there is really nothing
in Swing or Java that will ensure that an event listener will indeed
always be called from the EDT only.

If you tamper with a component (maybe subclass), it should be possible
to fire each or at least most events of the particular component from
outside the EDT. And since the event listeners are just callback
methods, one could even call the methods completely separately from
Swing, and from another thread if one has the necessary object
reference.

So in theory on should check in each and every event listener method if  
it is invoked from the EDT. In practice, I would not do this at all! If
you have written clean code, this is something that shouldn't happen at
all. But, because things that shouldn't happen sometimes happen, you
might consider to add some assert() calls to your event listeners. I
would also not do this (it never happened to me, and I am lazy :-)),
but if you feel unsafe and need some hints for debugging, why not?

Back to property changes. I see a particular problem with those, which
some might want to investigate further. There are some very few Swing
methods which are marked as thread save, and can be called from outside
the EDT. If one such method triggers a property change event, I would
guess the event listeners are not called from the EDT, too. But that's
a guess, and someone would have to spent some time to come up with a
real example.

Yes, in the general case it should.

I use an adapter class to propagate PropertyChangeEvents when they may
be generated in another thread than the GUI dispatcher thread. The
following snippet contains the essential parts of it:

import java.beans.PropertyChangeEvent;
import java.beans.PropertyChangeListener;
import javax.swing.SwingUtilities;

public class SwingPropertyChangeListener
implements PropertyChangeListener {

private final PropertyChangeListener listener;

public SwingPropertyChangeListener(PropertyChangeListener listener) {
 this.listener = listener;
}

public void propertyChange(final PropertyChangeEvent evt) {
 if (SwingUtilities.isEventDispatchThread()) {
  listener.propertyChange(evt);
 } else {
  SwingUtilities.invokeLater(new Runnable() {
   public void run() {
    listener.propertyChange(evt);
   }
  });
 }
}
}

Note that if this pattern is used for other types of events that have
mutable properties and which are reused by the emitter, additional code
is needed to avoid a race condition. The above code do not have that
problem since PropertyChangeEvent (in practice) is immutable.

Regards,