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.
