Swing Event Notification Ordering

A problem that I run into from time to time is listeners getting callbacks in a different order than I want. For example, I might have a model that I want updated before I display something that uses it, but both the model update and the display get triggered by a mouse event. If they get handled in the wrong order, then the display will be incorrect.

There is an open bug regarding this issue and some discussion about it here and here. However, I don't believe Sun has addressed it yet.

One solution would be to rely on the fact that listeners get notified in the reverse order that they were added. But officially the order is undefined, which could cause your code to break if the Java SDK changes.

If you want to be called after other listeners have been notified, a better solution is to use SwingUtilities.invokeLater(), which adds your Runnable to the end of the EDT (event dispatcher thread). This works for the example above.

I'm not sure what would be a good way to get called before other listeners though.

No to Java Serialization

After looking into Java's serialization API, I've decided that I wouldn't want to use it in most situations when using it to store data (mainly for application preferences and state). My main gripe is versioning. It seems too fragile when you consider what might change between versions, and between JVMs. If any errors occur when loading an object, the data is gone. I think there needs to be a way to read in as much of an object as you can, initialize other fields to defaults, and discard what you don't recognize. Sure you don't have the same level of certainty that the object is what you expected, but at least you get something if you have a bug (god forbid) in version compatibility.

There's not very much that you can change without having versioning problems. Adding fields requires no extra work, but almost any other change does. Granted there's probably a way to resolve every difference between versions, but maintaining the code after several versions seems like it would be a nightmare to me. Mark Davis wrote a good article of the considerations associated with serialization. Effective Java, one of the most recommended books on Java, starts out the chapter on serialization with the problems with serialization, and continues with techniques for getting around them (which require more work) and what to watch out for. To me, this is not a good indication. I found a good discussion of alternatives at stackoverflow.

For now, I'll stick to what I've been using: saving and loading object data to and from a java.util.Properties object. It doesn't support structured data, but I can fake it using the key strings (i.e. person_1234_firstname). Sure, not very efficient, but it's fine for the amount of data I have to save. XML would probably be my second choice.