Do you know XStream? It is a very famous, “magic” XML serialization framework.

It simply serializes an object tree using reflection. As default it uses the fully qualified names to be able to deserialize it later. But you can easily add aliases to tweak the XML.

The last project I worked for, used XStream very intensive. And it seems to be such a good choise. It is mature, well tested and simply does what you want.
And yes – I don’t know any other tool that offers such a good result out of the box with only very little work (”magically”).

I am sure there are several use cases where XStream is just great and does exactly the job. But sometimes XStream is the wrong choice. And it is hard to identify those situations. I personally have chosen the wrong tool for the job a few times. So here comes a simple don’t related to XStream.

XStream must not be used for mid/long term serialization.

In the project I have worked on, we used XStream to serialize settings to the file system. That really worked well. But one day we have to ship the next release of your software. And we will have to support the old  settings file…

XStream offers some support for refactorings (aliases can help). But very soon you will run into big troubles and will have to make some decisions. Either avoid refactorings (just a little tweak here and there, will weaken your architecture over time) or start implementing workarounds – e.g. custom converters (much work, bad code).

I think for mid/long term serialization it is absolutely necessary to add version information to those files. And it is absolutely necessary to handle that information correctly on deserialization. This opens the door for all kind of improvements and refactorings. You will always be able to identify the version of the serialized object (no wild guesses depending on some attributes anymore) and convert them accordingly.

Your serialization code will been kept clean. Legacy support is clearly separated…

And that leads to cedarsoft Serialization. More details will follow…