"Undoing" Java

In a relatively quiet week in the Java world, this week we pick through the Java Developer's forum, examine electronic indecision, and kick some stones--so to speak.

The Java Developer Connection has been Sun's method for collecting more information about the people using Java by insisting that they "register" for the otherwise free service in order to receive access to advance copies of specifications and software from JavaSoft.

All in all it's probably a forgivable intrusion (we can think of far more sleazy and less intelligent methods for feeding the marketing machine)--and there have been a few worthwhile support efforts offered under its banner. I've been meaning to give it a final once-over since it originally fragmented away from the regular Java Web site (I'm not a big fan of fragmenting, if you can't tell), and this week, finally got around to it).

Perhaps most interesting is the chat room; the support myth among software vendors is at least partially honored here--that is, they'll actually spend the (fairly considerable amount of) money required to put really qualified employees out in the open to share their expertise with the user community instead of locking all their qualified people up in a small room somewhere in the Midwest to "write the next version."

In particular, the archives of  Code Clinic chat sessions were particularly fraught with the perilous realism that can only be imparted by people who are seriously hitting Java's current set of brick walls. It's well worth reading, even if just to get a feel for the general problems associated with Java authoring. The set of Java papers available there also included a few pieces of interest. Having just spoken about object distribution, persistence, and JavaSpaces, I noticed and particularly liked the article called Persistent Reality.

I've mentioned indecision; what I'm really talking about is the coming generic support for "Undo" in Java. The JFC Undo API, which I've alluded to earlier, is designed to provide a general method for making the standard Macintosh (or should we say Xerox?) Undo command work in Java applications.

To be completely accurate, this is really a toolkit designed to make it easier to make this functionality happen by standardizing the easiest steps of the process. It's only a framework, and the real substance of any Undo system you might want to create would still need to be filled in around it--but all the same, it's a very interesting exercise just to see and understand how this kind of programming task can be made abstract, both from the standpoint of object-oriented programming and of Java's API.

I'm sure most of you readers have had some experience with Undo by now. You accidentally delete something, gasp, and select Undo from the ubiquitous Edit menu--and it becomes undeleted. Problem solved. Chances are, however, that most of you are not very familiar with the underlying mechanism that makes it work.

Think about it. Common sense will suffice to reverse-engineer this technology. Your word processor (for instance) must simply remember the substance of changes you make to your document. It stores the differences between each "version" of your file that are created as you type (or delete, or change the formatting, or anything else), so that it can apply them in reverse should you decide any of those changes were a mistake.

Of course, Undo is something that transcends word processors. It's an entire philosophy of computing. Ideally, any change you make to your computer should be undoable, or so many developers and theorists agree.

So a general undo system can't just remember different versions of a text document. It may need to backtrack through changes to a spreadsheet, or an image file . . . or perhaps changes to your operating system's configuration, or the arrangement of the files on your disk.

This ultimately demands that each system that can produce a unique kind of change will also be able to manage how things are Undone and Redone to it. And what the API provides is a framework for plugging in these different behaviors, based on the event queue and some simple objects that developers may inherit from.

Next week, we'll talk in more detail about how this is done. Past installments of Java Jolt