JDK-4765383 : JTextArea.append(String) not thread safe
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.3.1,7
  • Priority: P5
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,solaris_2.6
  • CPU: generic,sparc
  • Submitted: 2002-10-18
  • Updated: 2017-05-16
  • Resolved: 2011-05-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7 b27Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Description

Name: sv35042			Date: 10/18/2002


FULL PRODUCT VERSION :
java version "1.3.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_01)
Java HotSpot(TM) Client VM (build 1.3.1_01, mixed mode)

FULL OPERATING SYSTEM VERSION :

SunOS modeler 5.6 Generic_105181-29 sun4u sparc
SUNW,Ultra-5_10

ADDITIONAL OPERATING SYSTEMS : all, I'd think



A DESCRIPTION OF THE PROBLEM :
The Javadoc for javax.swing.JTextArea says the "append"
method is thread safe.  It is not, and the error could
result in loss of data from the document.

The implementation uses this line and discards the possible
BadLocationException:

 doc.insertString(doc.getLength(), str, null);

Alternately, we could write the same code in 2 lines, with
numbers:

1   int len=doc.getLength();
2   doc.insertString(len,str,null);

The problem occurs if line 1 executes, then some other
thread alters the length of the document, then line 2
executes.  The possible results are that the data is
inserted at some place not the end of the document, or that
an attempt is made to insert data beyond the end of the
document, resulting in a BadLocationException, which is then
discarded, thereby loosing the data.

REPRODUCIBILITY :
This bug can be reproduced occasionally.

CUSTOMER WORKAROUND :
Wrap the Document with a Document offering an append method
and synchronize the append, insert, and remove methods.
Then use the document's append method instead of
JTextArea.append.  (Note, wrapping the document on a
JTextArea with wrapped lines brings about occasional
exceptions in the event dispatch thread as noted in the bug
with Sun internal review ID 163709.)
(Review ID: 163721) 
======================================================================

Comments
EVALUATION The root problem is that the interface to Document is not rich enough to perform reasonable operations such as append, and does not publicly expose any kind of locking/transactional/CAS functionality. It's not so much that JTextArea.append has a race condition, but it necessarily must have one. Append requires two operation on a document: find length and insert text. What happens if the text is modified between these operations? Either the new text is inserted somewhere (that was perhaps never logically at the end of the document), or BadLocationException is thrown. These errors do occur in real applications. A handful of methods throughout the text package claim thread-safety falsely: JTextComponent.replaceSelection() JTextComponent.setText() JTextArea.append() JTextArea.insert() JTextArea.replaceSelection() JEditorPane.replaceSelection() JEditorPane.setText() JTextPane.insertComponent() JTextPane.insertIcon() JTextPane.replaceSelection() JTextPane.setCharacterAttributes() JTextPane.setParagraphAttributes() JTextPane.setLogicalStyle()
24-01-2008