United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4458513 : JTextComponent.replaceSelection() no longer calls doc remove() & insertString()

Details
Type:
Bug
Submit Date:
2001-05-14
Status:
Resolved
Updated Date:
2001-06-22
Project Name:
JDK
Resolved Date:
2001-06-22
Component:
client-libs
OS:
generic
Sub-Component:
javax.swing
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.4.0
Fixed Versions:
1.4.0 (beta2)

Related Reports
Relates:

Sub Tasks

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


                                     
2004-06-14
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
                                     
2001-05-15



Hardware and Software, Engineered to Work Together