<Swing Dev> [9] Review Request for 8030702: Deadlock between subclass of AbstractDocument and UndoManager
Semyon Sadetsky
semyon.sadetsky at oracle.com
Thu Sep 24 17:27:02 UTC 2015
On 9/22/2015 5:04 PM, Semyon Sadetsky wrote:
>
>
> On 9/22/2015 4:18 PM, Alexander Scherbatiy wrote:
>> On 9/21/2015 12:19 PM, Semyon Sadetsky wrote:
>>>
>>>
>>> On 9/21/2015 11:27 AM, Alexandr Scherbatiy wrote:
>>>> 18.09.2015 19:22, Semyon Sadetsky пишет:
>>>>>
>>>>>
>>>>> On 9/18/2015 6:51 PM, Alexander Scherbatiy wrote:
>>>>>> On 9/16/2015 5:14 PM, Semyon Sadetsky wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 9/16/2015 1:38 PM, Alexander Scherbatiy wrote:
>>>>>>>> On 9/15/2015 10:37 PM, Semyon Sadetsky wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 9/15/2015 6:16 PM, Alexander Scherbatiy wrote:
>>>>>>>>>> On 9/11/2015 7:24 PM, Semyon Sadetsky wrote:
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The deadlock that you described exists only because
>>>>>>>>>> AbstractDocument uses locks in the UndoableEdit.undo()/redo()
>>>>>>>>>> methods.
>>>>>>>>>> Applications that use UndoManager and do not use lock in
>>>>>>>>>> the UndoableEdit.undo()/redo() methods do not have deadlock.
>>>>>>>>>> They worked fine before the fix and can lost data consistency
>>>>>>>>>> after the fix. This is definitely the regression.
>>>>>>>>> You mean scenario when a document that does not support
>>>>>>>>> synchronization but anyway is modified from several threads.
>>>>>>>>> You can expect that such scenario is functional only if such
>>>>>>>>> document is a single atomic field.
>>>>>>>>> I updated the fix
>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8030702/webrev.04/ take
>>>>>>>>> it into account.
>>>>>>>>
>>>>>>>> This looks better. There are just some comments:
>>>>>>>> - The 'inProgress' variable in
>>>>>>>> UndoManager.undo()/redo()/undoOrRedo() methods should have
>>>>>>>> synchronization.
>>>>>>>> Is it possible to move 'if (inProgress)' check into
>>>>>>>> tryUndoOrRedo() method similarly to as it was used in the
>>>>>>>> version 2 of the fix?
>>>>>>>> - UndoManager line 489: why not to use the original check
>>>>>>>> from the undoOrRedo() method "if (indexOfNextAdd ==
>>>>>>>> edits.size())" to pick up undo or redo action?
>>>>>>>> - UndoManager line 516: An undoable edit can be requested
>>>>>>>> two times for the ANY action because the 'undo' variable can
>>>>>>>> have old value in the second synchronized block.
>>>>>>>> Even the logic is right it is better to take an edit based
>>>>>>>> on the 'action' variable.
>>>>>>>> - UndoManager.undoOrRedo() throws CannotUndoException now
>>>>>>>> instead of CannotRedoException if the redo action is not
>>>>>>>> possible.
>>>>>>>> - It is possible to get rid of the 'done ' variable in
>>>>>>>> UndoManager.tryUndoOrRedo() just simply have an infinity loop.
>>>>>>>> - It is possible to use Boolean values TRUE, FALSE or null
>>>>>>>> for three-state logic. But it is up to you to choose enums or
>>>>>>>> Boolean in the fix.
>>>>>>>>
>>>>>>> I made the changes:
>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8030702/webrev.05/ except
>>>>>>> for the last one. Actually triple Boolean logic is a bad style.
>>>>>>
>>>>>>
>>>>>> There are two main synchronized block in the tryUndoOrRedo()
>>>>>> method: one to look up an undoable edit lock and the second which
>>>>>> use the undoable edit lock.
>>>>>> In the version 02 of the fix the original code from undo()
>>>>>> and redo() methods were moved to these two blocks.
>>>>>> It is not clear why don't you want to do the same (just call
>>>>>> tryUndoOrRedo() with necessary argument for all
>>>>>> UndoManager.undo()/redo()/undoOrRedo() methods) in the latest fix?
>>>>>>
>>>>>> Splitting logic like:
>>>>>> -------------------
>>>>>> 420 public void undo() throws CannotUndoException {
>>>>>> 421 if (!tryUndoOrRedo(Action.UNDO)) {
>>>>>> 422 synchronized (this) {
>>>>>> 423 super.undo();
>>>>>> 424 }
>>>>>> 425 }
>>>>>> 426 }
>>>>>> -------------------
>>>>>> always have a question that before the fix the super.undo() was
>>>>>> called only for '!inProgress' condition but now the 'inProgress'
>>>>>> can be changed when super.undo() is called.
>>>>>>
>>>>> inProgress can be changed when super.undo() is called because it
>>>>> is protected by synchronized block.
>>>>> Imagine that undo() is called with inProgress = true, then it is
>>>>> blocked by the concurrent document change, and after the retry it
>>>>> finds inProgress= false, so it cannot undo by usual way anymore,
>>>>> because the UndoManager is converted into a single edit and it
>>>>> should undo using super.undo().
>>>>
>>>> I am talking about slightly different thing.
>>>> This is the code for the undo() method before the fix.
>>>> -------------------
>>>> 410 public synchronized void undo() throws CannotUndoException {
>>>> 411 if (inProgress) {
>>>> 412 UndoableEdit edit = editToBeUndone();
>>>> ...
>>>> 416 undoTo(edit);
>>>> 417 } else {
>>>> 418 super.undo();
>>>> 419 }
>>>> 420 }
>>>> -------------------
>>>>
>>>> Checking the 'inProgress' variable and calling undoTo(edit) and
>>>> super.undo() is done under the same synchronized block.
>>>>
>>>> Let's slightly modify the code:
>>>> -------------------
>>>> public void undo() throws CannotUndoException {
>>>>
>>>> boolean res = true;
>>>>
>>>> synchronized (this) {
>>>> if (inProgress) {
>>>> UndoableEdit edit = editToBeUndone();
>>>> ...
>>>> undoTo(edit);
>>> It is not possible to execute undoTo() here because it will cause
>>> the deadlock we are trying to fix.
>>
>> May be with the updated sample it would be cleaner.
>> This is just a some method which uses a synchronization:
>> ----------------------
>> public synchronized void someMethod() {
>> if (inProgress) {
>> // do something
>> } else {
>> // do something else
>> }
>> }
>> ----------------------
>>
>> This is an updated method:
>> -------------------
>> public void someMethod() {
>>
>> boolean res = true;
>>
>> [some synchronization]
>> if (inProgress) {
>> // do something
>> } else {
>> res = false;
>> }
>> [end of some synchronization]
>>
>>
>> [some synchronization]
>> if (!res) {
>> do something else
>> }
>> [end of some synchronization]
>> }
>> -------------------
>>
>> The problem with the updated method is that inProgress variable can
>> have a value different from 'res' and the 'do something else' action
>> can be executed even inProgress is true.
> InProgress goes only one direction true->false. Once it detected as
> false the super method should be called always.
Alexander, the version as per our off-line discussion:
http://cr.openjdk.java.net/~ssadetsky/8030702/webrev.06/
>>
>>>> } else {
>>>> res = false;
>>>> }
>>>> }
>>>>
>>>> synchronized (this) {
>>>> if (!res) {
>>>> super.undo();
>>>> }
>>>> }
>>>> }
>>>> -------------------
>>>>
>>>> Now the 'inProgress' variable checking and undoTo() is done on
>>>> the first synchronized block.
>>>> The result of the inProgress is used in the second synchronized
>>>> block. But the 'inProgress' variable
>>>> can be changed between these two blocks and we can't relay on the
>>>> 'res' value.
>>>> Instead of 'res' the original 'inProgress' value should be
>>>> checked in the second synchronized block and if it is true the
>>>> undoTo(edit) should be called again instead of super.undo().
>>>>
>>> Above you provided the code logic bore the fix which is reworked
>>> because it does not work. Why do we need to discuss it?
>>
>> We need to discuss this because the inProgress variable in your
>> latest fix is used exactly as in the provided sample.
>> UndoManager line: 473 tryUndoOrRedo(action) returns false if
>> inProgress is false.
>> UndoManager line: 422 super.undo() is called if
>> tryUndoOrRedo(action) returns false despite the real 'inProgress'
>> variable value.
>>
>> Thanks,
>> Alexandr.
>>>>
>>>> Thanks,
>>>> Alexandr.
>>>>
>>>>>> Thanks,
>>>>>> Alexandr.
>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Alexandr.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Alexandr.
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>> Also synchronization is needed to provide coherency with
>>>>>>>>>>>>>>> the state of the document. If those two are not provided
>>>>>>>>>>>>>>> the document can be corrupted. This is enough most usages.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>>>>> It is
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I still think that updating the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoableManager for one particular
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> AbstarctManager class can be made only
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> after investigation of other
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> possibilities.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You could start with choosing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> behavior which you want to achieve or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to keep, like:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - fix the deadlock
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - atomic undo() method
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - serialization
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - immediate roll back action
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - abstract document consistency
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> after undo() action
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - ...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We need to pay attention to the deadlock
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> at first of cause.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Serialization and consistency are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> achieved. Any concrete doubts?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> immediate roll back action -- ?what is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "if user starts a long edit
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> operation and press undo after that he
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> expects when the long edit is finished it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will be rolled back immediately." - what
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ever does it mean.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Got it. It will work within the fairness.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We have discussed this allready.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I sacrificed undo/redo call atomicity
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> because you did not like doc references
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in undo manager. I think it is not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> important for the most multithreaded
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> undo/redo scenarios.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Could you give more details about it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Which doc references do you mean?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Your statement a dozen iterations ago was:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "There should be a way to solve these
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> problems without storing links of external
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> classes inside the UndoManager."
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I guess you used "link" term for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> references. I would recommend to use
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> standard terminology: reference to the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> object, dependency on the class, etc... to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> avoid misunderstanding.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Usually "link" is in a browser document or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a tool that produces executables after
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> compilation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and look which of the following
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> approaches can better solve them (where
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the fist is more preferred and the last
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is less preferred case):
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - using UndoManager as is without
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> adding links from some specific classes
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - provide an API for UndoManager to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> work with UndoableEdit-s which have
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> synchronization for undo/redo methods
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - adding links of external classes
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> directly to UndoManager
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> What do you mean under link term? A
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reference or dependency?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There are two options. If UndoManager
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is a class designed to be only used with
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the AbstractDocument and placed in the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> javax.swing.text package it definitly can
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> have special code to handle an abstract
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> document instance in a special way.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If UndoManager is a general purpose
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> class, it looks strange that it handles
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> some special classes in different way as
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> all others. It usually mean that there
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> are some design problems in this class.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That is why I just asked to look at other
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ways at first. Only if other solutions
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> are not suitable it has sense to look at
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the way that you are provided.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Correct. I introduced extra dependency. It
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is optional, but anyway. Of cause there is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a design problem in undo javax.swing.undo
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> package. But I cannot rewrite the API
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> because we will get a compatibility
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> problem then. I mentioned this several
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> times in this thread.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We are constrained by compatibility
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> requirements. UndoManager is a broadly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> used class we cannot change the API so
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> drastically.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think that you can generalize your
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> solution just adding an internal
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> interface like sun.swing.UndoableEditLock.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Every UndoableEdit which implements
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this interface can provide a lock for its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> synchronization.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If this will work it can be made
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> public in some days so other application
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can also have proper synchronization for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> their undo/redo actions.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> OK. I added it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8030702/webrev.02/
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> - We can return a public class that
>>>>>>>>>>>>>>>>>>>>>>>>>>>> implements an internal interface, but we
>>>>>>>>>>>>>>>>>>>>>>>>>>>> can't expose an internal API in the public
>>>>>>>>>>>>>>>>>>>>>>>>>>>> class definition.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> May be it is possible to wrap an
>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoableEdit to the UndoableEditLockSupport
>>>>>>>>>>>>>>>>>>>>>>>>>>>> in the UndoableEditEvent or in some other
>>>>>>>>>>>>>>>>>>>>>>>>>>>> place.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> - The similar code is used both in the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoManager.undo() and redo() methods. Is
>>>>>>>>>>>>>>>>>>>>>>>>>>>> it possible to move this code to one method
>>>>>>>>>>>>>>>>>>>>>>>>>>>> that does undo or redo depending on the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> given argument?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> OK. accepted.
>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8030702/webrev.03/
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> - UndoManager.undo/redo methods
>>>>>>>>>>>>>>>>>>>>>>>>>> In your previous fix inProgress variable
>>>>>>>>>>>>>>>>>>>>>>>>>> and the super call were used under the lock.
>>>>>>>>>>>>>>>>>>>>>>>>>> It may leads to some synchronization issues
>>>>>>>>>>>>>>>>>>>>>>>>>> if you decide to omit it.
>>>>>>>>>>>>>>>>>>>>>>>>>> - UndoManager.tryUndoOrRedo()
>>>>>>>>>>>>>>>>>>>>>>>>>> It is possible to get rid of 'done'
>>>>>>>>>>>>>>>>>>>>>>>>>> variable just using an infinity loop and
>>>>>>>>>>>>>>>>>>>>>>>>>> return the exact result where the loop is
>>>>>>>>>>>>>>>>>>>>>>>>>> terminated.
>>>>>>>>>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>>>>>>>>> AbstractDocument.DefaultDocumentEventUndoableWrapper
>>>>>>>>>>>>>>>>>>>>>>>>>> implements both UndoableEdit and
>>>>>>>>>>>>>>>>>>>>>>>>>> UndoableEditLockSupport interfaces but
>>>>>>>>>>>>>>>>>>>>>>>>>> UndoableEditLockSupport already extends
>>>>>>>>>>>>>>>>>>>>>>>>>> UndoableEdit.
>>>>>>>>>>>>>>>>>>>>>>>>>> - "@since 1.9" javadoc for
>>>>>>>>>>>>>>>>>>>>>>>>>> DefaultDocumentEventUndoableWrapper.lockEdit()/unlockEdit()
>>>>>>>>>>>>>>>>>>>>>>>>>> methods really belongs to the
>>>>>>>>>>>>>>>>>>>>>>>>>> UndoableEditLockSupport methods.
>>>>>>>>>>>>>>>>>>>>>>>>>> In this case there is no need for
>>>>>>>>>>>>>>>>>>>>>>>>>> {@inheritDoc} tag.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "adding links of external classes
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> directly to UndoManager" - Sorry, did
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not catch what are you about? Could you
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> clarify?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --Semyon
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --Semyon
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There is a mistake in your
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> scenario steps:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fireUndoableEditUpdate() is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> called before the freeing the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> lock (see
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> AbstractDocument.handleInsertString()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> method).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yet another argument do not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> do this from the user
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> experience: if user starts a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> long edit operation and press
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> undo after that he expects
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> when the long edit is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> finished it will be rolled
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> back immediately.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is not true. The first
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> process adds his undo edit to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the UndoManager. While a user
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> trying to press undo the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> second long process can be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> started.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That is what led to this issue
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> because when undo is in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> progress document writing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> should be allowed.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sorry but I didn't see why is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "It not true"? Then what is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> your expectation when you press
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> undo button while edit is not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> finished yet and there is no
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> way to abort it?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It would be good if it works
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> as you described. But it does
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not work in this way with or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> without your fix.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> undo() action has writeLock
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in AbstractDocument and because
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of it is always executed after
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> insert string action.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If a user sees that undo is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> available, he can call it but
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the second long insertString
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> process can start earlier and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> acquire the writeLock.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That is what we are going to fix.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> And this does work after this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fix. Undo call will be blocked by
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the long edit until the last is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> done without any deadlocks. And
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> when edit is done undo() will
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> acquire the lock and prevent any
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> new edits until undo() is done.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Please provide a scenario when in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> your opinion it does not wok.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The first process starts for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 5 minutes. When it is finished a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> user sees that he can press undo.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> While he is pressing undo button,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the second long process starts for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 10 minutes and acquire the write
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> lock. The user presses undo but he
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> needs to wait 10 more minutes
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> until the second process is finished.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Actually, if two or more threads
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> are waiting for a monitor it is not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> determined which one will get the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> control after the signal. To order
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that the ReentrantLock API could be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> used but AbstractDocument uses
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wait/notify for locking. I think it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is not worth to dig so deep. It
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does not cause any issues
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The issue that is considered is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "if user starts a long edit
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> operation and press undo after that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> he expects when the long edit is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> finished it will be rolled back
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> immediately."
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If you are agree that it is not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> always possible to do the roll back
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "immediately" there is no point to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> discussion.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I agree. On that level it is not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> possible to predict the order exactly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in such scenario. But the state of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the document will be consistent. And
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it is possible to have it predictable
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> using lock fairness.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> because undo() always get the last
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> edit anyway. If it will be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> important for somebody to preserve
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the execution order on that level
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of details we will fix it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So undo should be executed
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> after the edit is fully
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> performed because the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> corresponding UndoableEdit
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which undos this edit can be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> produced only after the edit
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is done.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think at first we need to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> look on the situation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> externally rather than
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> concentrate on implementation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> questions like in which class
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> do references go.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes, please look on this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> situation from a user point of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> view which wants to implement
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simple Java Painter.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But could you describe this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> scenario? Just steps when this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simple Painter fails under the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> proposed fix?I
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Note, if this Painter's content
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is not an AbstarctDocument it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will work as before the fix.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Any application that uses
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoManager and wants to have
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the same synchronization (have
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the same lock both for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoableEdit adding and undo()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> method execution) will have the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> same deadlock problems.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> As I have already written:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ---------------
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Consider someone writes Java
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Painter application where it is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> possible to draw lines and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> images and uses UndoManager for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> undo/redo actions.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> He might want that it was
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> possible to work with copied
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> images. He can get lock on
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ctrl+v action, process an image,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> prepare UndoableEdit and notify
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the UndoManager.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> He also can use lock/unlock
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in the undo action to have a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> consistent state with the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> processed image. If someone
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> calls undo action during the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> image processing and gets a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> deadlock does it mean that link
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from Java Painter need to be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> added to the UndoManager?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ---------------
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Still do not understand the steps
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for your Painter scenario. A link
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (reference?) can be added if it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is required to implement
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> functionality. If the content is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not an AbstarctDocument it may be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> required to implement custom
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoManager to support the same
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> behavior.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> What is the difference between
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the AbstractDocument and other
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> classes (in Swing or user
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> defined)? Do you mean that the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoManager is intended only to be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> used with AbstractDocument and it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> shouldn't be used in other cases
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> where undo/redo actions are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> required for non text data?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, undo manager can be used with
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> any classes. But since we have it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> assigned to AbstarctDocument so
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> often we need to do our best to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> make undo manager working with it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correctly because users do not like
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> deadlocks usualy. For other classes
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> we cannot provide synchronization
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> by default because there is no API
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to get the lock. So it remains up
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to user how to provide the undo
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> manager synchronization with the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> object it controls for other classes
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> What we should do just to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> understand that the same deadlock
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can happen in an user applications
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> because he wants to use the same
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> synchronization both for the data
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> processing and for the undo action.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If so, there should be two
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> investigations:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1. Is it possible to achieve the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> requested goals without changing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoManager? In other words The
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoManager should be used in proper
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> way as it is required by its design.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2. Is it possible to update the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoManager API to provide
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> functionality that meets new requests?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> With API change it is reachable. But
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I would preserve the current API as
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> less constrained. If we add some
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> methods for locking we will determine
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the way how a user should synchronize
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> his undoable content. And user may
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not need any synchronization at all.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We should keep in mind this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> opportunity as well.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Only after this discussion there
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can be a reason to look to other ways.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think our undo manager
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> implementation do not pretend to be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> used as the global undo manager for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> big complex applications and it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cannot cover all possible undo
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> approaches. But some basic
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> functionality can be provided and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it should be usable. Without edits
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> serialization approach it is not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> usable for multithreaded use. So
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> either we do not pretend to provide
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a multithreaded undo manager and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> remove all synchronize keywords
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from UndoManager class, either we
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> need to support serialization
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> approach which does not cause
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> deadlocks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I don't see a contradiction here,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> could you point on it more
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> precisely?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --Semyon
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --Semyon
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/30/2015 5:27 PM,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Consider someone
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> writes Java Painter
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> application where it is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> possible to draw lines
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and images and uses
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoManager for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> undo/redo actions.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> He might want that it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> was possible to work
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with copied images. He
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can get lock on ctrl+v
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> action, process an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> image, prepare
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoableEdit and notify
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the UndoManager.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> He also can use
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> lock/unlock in the undo
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> action to have a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> consistent state with
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the processed image. If
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> someone calls undo
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> action during the image
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> processing and gets a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> deadlock does it mean
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that link from Java
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Painter need to be added
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to the UndoManager?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It looks like
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> AbstractDocument
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> violates UndoManager
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> synchronization
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> contract when it both
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> use lock to work with
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoManager and in the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> implemented undo()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> method.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --Semyon
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
More information about the swing-dev
mailing list