More about the 0805 (i.e. August 5) Verdantium / JUndo Update

Now that the August 5 update is fully posted I wanted to log a little about this particular version. The new version is an unstable test version with an expanded undo capability. I've been coding on this version for a while now, and now that I have got something that is nominally working I wanted to archive it to sourceforge before it got accidentally deleted by something like a hard disk crash (stranger things have happened with my hard disk lately).

So this is a Verdantium release that is partially an advance, partially untested, and partially outright broken. The nexus of the Verdantium changes is the verdantium.standard.DrawApp class. This class now has a partial implementation of multi-level undo. Some of it is actually working quite well. You can add a series of lines to the DrawApp, and then undo them one by one. Other aspects of the implementation, especially DrawApp persistence, are completely broken while I finish writing the code.

As the name implies, "JUndo" is is a multi-level undo language for Java. Hence, it is spelled with a "J" for Java followed "Undo" for undo. JUndo is actually more than that, but undo is the primary practical issue that the language resolves. JUndo makes it feasible to use undo patterns that are difficult to implement in ordinary Java. Many typical systems use one of two patterns: either store a memento on every operation that encapsulates a copy of the entire data state, or create an inverse command for every command. The first is very computationally expensive and memory-consuming for programs storing large amounts of data (imagine making a copy of the entire data store every time you update a field), and the second tends to require the creation of very sophisticated command objects to undo operations such as deletions or sort operations (e.g. a command to sort a list requires an undo command that will "unsort" a list-- think about that the next time you bubble sort). JUndo solves these problems by providing objects which support a temporal model of undo. In Verdantium / JUndo undo, inverse commands aren't needed. The developer simply never needs to create an inverse command. Moreover, the JUndo system is very efficient at only storing changes between states, rather than generating memento patterns describing the entire state of a system.

Some of this can be seen in the new version of DrawApp. Some very complex operations are performed on the rendering primitives in DrawApp, and yet there is no need to create inverse commands. The elimination of inverse commands potentially makes the developer much more prroductive, and potentially makes the resulting system much more self-consistent. Inverse commands sometimes have bugs, and these bugs can produce inconsistent data states and systems that are not self-consistent. JUndo implementations avoid these inconsistencies. Further, operations tend to be fast because only changes to objects are stored.

As an example, primitives can be added to the DrawApp rendering list without the need to produce inverse commands to remove those items from the rendering list. Instead, the undo system simply remembers what the list looked like in its previous state and automatically takes the list back if the user performs an undo operation. This should become very impressive as the new implementation of DrawApp is fully developed. Developers can take advantage of these new extensions to the undo system in their own components.