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
