Link Details

The title is a bit too generic, but the point is well driven: there are use cases where XStream (and many other serialization tech, in my opinion) are the wrong choice. Preferences/config files are one of such cases.

Yes - you are right. The title is too generic.

But I hope all those XStream (and similar tools) lovers will get that point. The tools itself are great. They are just misused...

Point taken. Although I reckon most people end up, like I, with writing custom mapping for Xstream which is also dead simple. That gives the best of both world - XSteam is great for early in the dev cycle where you just can't be bothered by such versioning detail.

Yep. You *will* end writing custom mappings for XStream. So did I...
But I think this is not "best of two worlds"... It is a complicated workaround around a "problem" that is self made. And you are cursed to run into it when using XStream for mid/long term serialization...

I have written many custom converters in my life. At first that can be done easily. But two or three iterations later there are fancy hacks needed to determine between the different versions. And another iteration later you start thinking about dropping support for old setting files...

Custom converters are not the solution. They are a symptom.

We can all agree that adding versioning info is great. But remember XStream started as an alternative to the ivory-tower JAXB stuff, which has since improved much in the 2.0 iteration. JAXB has its own share of problems though, i.e. being a fan of single responsibility, I find that the annotation mapping pollutes the domain. It does however have an interesting solution to the versionability problem, by only serializing the difference between a bean and a reflectively created instance - but again, this can lead into some pretty hairy debugging by my experience. Bottom line, a format is a contract. Once published, you can not change this contract and if you do, you need to have a migration compatibility layer.