Some methods in JTextComponent (and probaly in some of its descendants)
have the following remark in their javadoc:

     * This method is thread safe, although most Swing methods
     * are not. Please see
     * <A HREF="http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html">How
     * to Use Threads</A> for more information.

Let's take the JTextComponent.setText() for example,
looking to its code it is quite obvious that it can't be tread safe

                doc.remove(0, doc.getLength());
                doc.insertString(0, t, null);

Desptite the fact that AbstractDocument correctly takes the lock for both remove() and insertString() methods, the document can be updated by another thread in the middle of the action, which will lead to an incorrect state

Surprisingly, the javadoc of JTextComponent.getText()
doesn't have any note about thread safety, but is not thread safe either
  
Examine the following line: txt = doc.getText(0, doc.getLength());

if documents' length is changed during the invocation of doc.getText() method,
you may get a BadLocationException

Conclusion:
Thread safety of the AbstractDocument class doesn't mean the same for the JTextComponent class

Expected fix:
Remove all remarks about thread safety from the JTextComponent class and all its subclasses