JDK-4458513 : JTextComponent.replaceSelection() no longer calls doc remove() & insertString()
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.4.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2001-05-14
  • Updated: 2001-06-22
  • Resolved: 2001-06-22
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.
Other
1.4.0 beta2Fixed
Related Reports
Relates :  
JDK-4431047 - JFormattedTextField should treat replace as an atomic edit
Description
In merlin-beta2, a new method replace() was added to AbstractDocument so that replacing of text could be considered an atomic operation. This method is designed to get its own lock on the document and not go through remove() and insertString(). JTextComponent.replaceSelection() was changed to call this method when possible.

Although this is a very desirable change, it can possibly cause backwards compatibility problems to users extending AbstractDocument that expect all document changes to come through the two old methods.
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: merlin-beta2 FIXED IN: merlin-beta2 INTEGRATED IN: merlin-beta2
14-06-2004
EVALUATION replace doesn't call remove then insertString as it first grabs a writeLock, then does the mutation. insertString and remove both also attempt to grab a writeLock, hence the inability for replace to call them. There is really no reason why we don't allow multiple calls to writeLock from the same thread that grabbed the lock. We just need to make sure non of the listeners attempt to mutate the Document, as such we will now allow additional writeLocks to be grabbed from the first thread that obtained the writeLock as long as not in the middle of document notification. The documentation for writeLock/writeUnlock will be updated to: The documentation of writeLock will change to: /** * Acquires a lock to begin mutating the document this lock * protects. There can be no writing, notification of changes, or * reading going on in order to gain the lock. Additionally a thread is * allowed to gain more than one <code>writeLock</code>, * as long as it doesn't attempt to gain additional <code>writeLock</code>s * from within document notification. Attempting to gain a * <code>writeLock</code> from within a DocumentListener notification will * result in an <code>IllegalStateException</code>. The ability * to obtain more than one <code>writeLock</code> per thread allows * subclasses to gain a writeLock, perform a number of operations, then * release the lock. * <p> * Calls to <code>writeLock</code> * must be balanced with calls to <code>writeUnlock</code>, else the * <code>Document</code> will be left in a locked state so that no * reading or writing can be done. * * @exception IllegalStateException thrown on illegal lock * attempt. If the document is implemented properly, this can * only happen if a document listener attempts to mutate the * document. This situation violates the bean event model * where order of delivery is not guaranteed and all listeners * should be notified before further mutations are allowed. */ protected synchronized final void writeLock(); /** * Releases a write lock previously obtained via <code>writeLock</code>. * After decrementing the lock count if there are no oustanding locks * this will allow a new writer, or readers. * * @see #writeLock */ protected synchronized final void writeUnlock(); scott.violet@eng 2001-05-15 I have added stack trace for exception thrown in Pilsen CE build 010620_1. This should help us to identify this issue, if we will search it anytime. ###@###.### 2001-06-21
15-05-2001