XStream or Simple

Question

I need to decide on which one to use. My case is pretty simple. I need to convert a simple POJO/Bean to XML, and then back. Nothing special.

One thing I am looking for is it should include the parent properties as well. Best would be if it can work on super type, which can be just a marker interface.

If anyone can compare these two with cons and pros, and which thing is missing in which one. I know that XStream supports JSON too, thats a plus. But Simple looked simpler in a glance, if we set JSON aside. Whats the future of Simple in terms of development and community? XStream is quite popular I believe, even the word, "XStream", hit many threads on SO.

Thanks.

Answer 1

Just from reading the documentation (I'm facing down the same problem you are, but haven't tried either way yet; take this with a grain of salt):

XSTREAM

1. Very, very easy to Google. Examples, forum posts, and blog posts about it are trivial to find.
2. Works out of the box. (May need more tweaking, of course, but it'll give you something immediately.)
3. Converting a variable to an attribute requires creating a separate converter class, and registering that with XStream. (It's not hard for simple values, but it is a little extra work.)
4. Doesn't handle versioning at all, unless you add in XMT (another library); if the XML generated by your class changes, it won't deserialize at all. (Once you add XMT, you can alter your classes however you like, and have XStream handle it fine, as long as you create an increasing line of incremental versioning functions.)
5. All adjustments require you to write code, either to implement your own (de)serialization functions, or calling XStream functions to alter the (de)serialization techniques used.
6. Trivial syntax note: you need to cast the output of the deserializer to your class.

SIMPLE

1. Home page is the only reliable source of information; it lists about a half-dozen external articles, and there's a mailing list, but you can't find it out in the wild Internet.
2. Requires annotating your code before it works.
3. It's easy to make a more compact XML file using attributes instead of XML nodes for every property.

4. Handles versioning by being non-strict in parsing whenever the class is right, but the version is different. (i.e., if you added two fields and removed one since the last version, it'll ignore the removed field and not throw an exception, but won't set the added fields.) Like XStream, it doesn't seem to have a way to migrate data from one version to the next, but unlike XStream, there's no external library to step in and handle it. Presumably, the way to handle this is with some external function (and maybe a "version" variable in your class?), so you do

   Stuff myRestoredStuff = serializer.read(Stuff.class, file); myRestoredStuff.sanityCheck();

5. Commonly-used (de)serializing adjustments are made by adding/editing annotations, but there's support for writing your own (de)serialization functions to override the standard methods if you need to do something woolly.

6. Trivial syntax note: you need to pass the restored object's class into the deserializer (but you don't need to cast the result).

Answer 2

Why not use JAXB instead?

• 100% schema coverage
• Huge user base
• Multiple implementations (in case you hit a bug in one)
• Included in Java SE 6, compatible with JDK 1.5
• Binding layer for JAX-WS (Web Services)
• Binding layer for JAX-RS (Rest)
• Compatible with JSON (when used with libraries such as Jettison)

Useful resources:

• Comparison, JAXB & XStream
• Comparison, JAXB & Simple