XStream: how to serialize objects to non XML formats
As you know, XStream makes it easy to serialize objects to XML:
Person person = ...; xstream.toXML(out);
Producing:
Joe Walnes 123 433535 4545 4534
I often use this approach whilst debugging to dump out the contents of an object. It works, but my eyes just aren’t that good at parsing XML.
By creating an alternative writer implementation, XStream can be used to serialize objects in other formats:
Person person = ...; xstream.marshal(stuff, new AnAlternativeWriter(out));
Producing the slightly more digestible:
com.blah.Person firstName = Joe lastName = Walnes homePhone areaCode = 123 number = 433535 cellPhone areaCode = 4545 number = 4534
To gain roundtrip serialization/deserialization support in alternative formats to XML, you need to provide your own implementations of both HierarchicalStreamWriter and HierarchicalStreamReader.
Joe Walnes 
As noted here you can also use XStream to serialize/deserialize objects directly into an XML:DB database such as Xindice or eXist, by using the SAX integration. That way you have a nice “lightweight” object storage that you still can use XML tools to analyze and work with.
Damnit, the link was stripped from my comment. Oh well, here it is:
http://jroller.com/page/rickard/20041218
Nice one, Joe.
Had a crack at YAML (http://yaml.org) yet?
YAML would be awesome – it would allow for very easy Java/Ruby interop!
With a YamlStreamWriter and a YamlStreamReader XStream would become a fully working Java YAML implementation. They shouldn’t be that hard to implement methinks.
I imagine YAML would be quite easy to do.
As would a mechanism for serializing a complete object graph to java.util.Properties format.
Something I’m more interested in doing is a binary representation that’s a lot more compact than the standard Java serialization format.
Joe, my integration with the Xindice XML database is a little interesting with regard to the binary representation. If I understand it correctly it stores the DOM internally, but uses a symbol table to make it small. I suppose you could do something similar as a custom serializer, i.e. write a symbol table along with a “binary” representation of the output tree. That should work ok. It’d still be XML, just a little more compact than the text variant.
However, if you search for “binary XML” on Google there seems to be a lot of heated arguments about whether binary XML is a good idea at all.
*shrug*
How about serializing to the serialised object formats of other languages, like Python, Ruby or PERL?
Writing YAML would be pretty easy (YamlStreamWriter). Implementing a YamlStreamReader that reads YAML would probably be a bit harder, since the YAML spec is not trivial (http://www.yaml.org/spec/).
A YamlStreamReader could be written based on the following approaches:
1) Port Syck (http://whytheluckystiff.net/syck/) from C to Java (manually or with the help of a C-to-Java translator)
2) Implement a YAML parser from scratch, using a similar approach to http://homepages.ihug.com.au/~zenaan/zenaan/files/ more notably this (retired?) one based on ANTLR (http://homepages.ihug.com.au/~zenaan/zenaan/files/yamljava/)
Perhaps a JFlex grammar could be generated from the YAML spec page?
3) Implement a lo-fi parser that can only parse “simple” YAML documents.
I would think option 1 or 2 are the best options in the long run.
Answer to Anonymous Coward regarding object formats like Python, Ruby or PERL: YAML is the way to go I think. All of these languages support YAML.
Hi Joe,
I posted a question on the XStream user mailing list, without answer yet. May be you have an idea of how I can handle deserializization of XML file that contains a repeted object. I used the “Frequently Ask Questions” example to do my testing. Create XML from Java Class Object is pretty straith forward but repopulate your objects when there is more than one of the same object is not really trivial. If you have any input that will be really great. Thanks in advance. Cheers.
Indeed, compact binary format will be an awesome addition to the excellent XStream package. Default Java serialization has its problems and there is the need for fast, memory efficient and compact binary serialization. BTW, I am sure you have looked at Hessian and Burlap (from the makers of the Resin app. server)