<Swing Dev> [9] Review Request for 8030702: Deadlock between subclass of AbstractDocument and UndoManager

[Semyon Sadetsky]

Good question. But I did not add a concrete class.
The problem is that UndoManager provided by JDK wants to be serialized 
but undoable objects knows nothing about that. The contract between 
UndoManager and undoable is UndoableEditListener which only notifies 
UndoManager to add a new edit. AbstractDocument does not care about the 
specific UndoManager implementation and it can contain plenty different 
UndoableEditListener. That is the current API approach.
If our specific UndoManager wants to be serialized it should also take 
into account that the undoable it controls may require serialization. 
For that it needs undoable's synchronization monitor and 
AbstractDocument can provide it using writeLock()/writeUnlock() methods. 
I assumed that in the first turn UndoManger should work well with JDK 
undoables than to serve as a general implementation. Also I tried to 
preserve  the current API.
And your suggestion is to change the existing UndoableEditListener API 
by introducing synchronization methods in it. Am I correctly understand you?

--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
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20150731/66ad3ac8/attachment.html>