I have a doubt about The Single-Thread Rule

Question

The [url http://java.sun.com/docs/books/tutorial/uiswing/overview/threads.html#rule]Single Thread Rule states:
Rule: Once a Swing component has been realized, all code that might affect or depend on the state of that component should be executed in the event-dispatching thread.
I began to wonder about this because so much code seems to work just fine when it isn't executed in the event dispatching thread. Why are there exceptions? I went looking for some code which acted differently when executed on the event thread than when it was not. I found this
http://forum.java.sun.com/thread.jsp?forum=57&thread=410423&message=1803725#1803725
Now I started wondering why this was the case. What I found was that DefaultCaret adds a document listener to the document of the JTextComponent. In this listener, the insertUpdate() method specifically tests if it is running on the event dispatch thread and if it is, it updates the caret position.public void insertUpdate(DocumentEvent e) {
    if (async || SwingUtilities.isEventDispatchThread()) {
        // ... update the caret position ...
}I then copied the code from DefaultCaret and made a MyCaret. I needed to tweek the code a little bit, but it ran. I removed the event thread test. It worked outside the event thread. There was a small difference in the results though. The textarea did not scroll all the way to the bottom. Almost, but not quite. I didn't test enough to make sure this was the only problem, but there was at least one problem.
Now I started think about why this would be. The thought crossed my mind that the order of the events which were posted to the event queue were probably important. Sun found bugs when components were updated out of the event thread, so they essentially ignored events which weren't on the event thread and created the The Single-Thread Rule.
A few days pass. I'm starting to wonder if Sun could have done a better job making Swing components thread safe. I also don't know that this specific case I found was the rule or the exception to the rule. But without insight into the design philosopy of Swing, I would have to examine all their components and see how they have written them and see if I can come up with a better design. That sound like a lot of work. Especially without getting paid for it.
But wait a second, all you have to do is call the append() method of JTextArea on the event thread. If that is the case, why didn't they write the freakin component that way? Well, I'll try itclass MyTextArea extends JTextArea {
  public MyTextArea(int rows, int columns) { super(rows,columns); }
  public void append(final String text) {
    if (SwingUtilities.isEventDispatchThread()) super.append(text);
    else {
      SwingUtilities.invokeLater(new Runnable() {
        public void run() { myAppend(text); }
  private void myAppend(String text) { super.append(text); }
}I change [url http://forum.java.sun.com/thread.jsp?forum=57&thread=410423&message=1803725#1803725]camickr's code to use a MyTextArea and it works fine without calling from the event thread. I've essentially moved The Single-Thread Rule to the component itself rather than relying on each and every one of the [url http://www.aboutlegacycoding.com/default.htm?AURL=%2FSurveys%2FSurvey6intro%2Easp]2.5 million Java programmers worldwide to use SwingUtilities.invaokeLater().
Now for my question...
Why didn't Sun do this?

Answer 1

Swing is slow enough as it is. Lets not make it slower
just
because dense "programmers" don't know what they are
doing.I agree with you in defending the current model, but aren't you a bit harsh there?!? ;-)
Well, there are a number of not-so-dense programmers that expect such high-level components to be thread-safe. The question is worth asking whether Sun intentionally favor the explicit thread management for performance reasons, or whether this was an oversight.
I'd go for the former (intentional) : indeed any GUI toolkit is inherently thread-based; there is always a distinction between the graphical thread(s) and the application threads - and the programmer always has to manage explicit thread creation to handle long-running event handlers without blocking the event dispatching thread. Extending thread concerns to the updating of components is therefore not a big move.
So it seems fair that a core GUI toolkit does not hide thread issues (though to the best of my knowledge there is no such limitation in updating AWT components), or at least that's what Sun deemed.
An ease-of-use-focused toolkit wrapping the core toolkit for thread-safety can be provided as a third-party product. Though I agree that wrapping the dozens of existing widgets and hundreds of methods is cumbersome - and the lack of such products probably shows it would have a low added value to trained developpers.
Because your way is an extra method call and if
statement, neither of which is necessary if you already know you
are in the correct thread. Now count the number of methods
which will need to be changed (and add up the extra cost).Indeed it's quite common to update several properties of several widgets in one bulk (when user clicks "OK", add a row to the table, change the title of the window, update status bar, re-enable all buttons, change some color,...).
In this case explicit thread management doesn't spare one if but a dozen of redundant ifs!
Note that there could have been if-less ways to cope for thread safety, such as creating a copy of the component's model when a change is made to a component, and switching the model only before paint() is called in the event-dispatching - of course coalescing all changes into the same "updated" model until paint() is called.
But this would trade ease of use for redundant memory consumption, especially for some components with potentially huge models (JTree, JTable, JTextArea,...). And Swing appears to be already quite memory-greedy!