This post originated from an RSS feed registered with Java Buzz
by scot mcphee.
Original Post: XStream vs Castor for XML serialization
Feed Title: SystemExxception()
Feed URL: http://www.autonomous.org/pebble/systemexxception/rss.xml?category=Java
Feed Description: java design and culture by scot mcphee
I just want to thank the developers of Xstream for their work on this product, and their attention to details in enabling the end-user to get it up and running so quickly and without a lot of fuss.
Here is the success story of XStream so far.
We were trying to use Castor to serialize Java objects to XML, and it failed. Previously we used Castor to map from a generated object model to XSD schema and this worked relatively well. We had a requirement to use XML persisted Java objects for matters like logging and user request data and report reconstruction. We had tried to use Castor with no success for this purpose for several days.
Due some limitations in the object model we had a home grown type-safe Enum type (abstract) with many sub-classes (some dozens). This runs under JDK 1.3. Because of the lack of a default constructor Castor could not handle this type. We looked at using Castor mapping files, and custom field persisters and whatnot. Eventually we discovered that the only way to do this was to make modifications to every Enum sub class, and map every single class that had a field of an Enum sub type. This amounted to many hundreds if not thousands of lines of mapping file and was an unacceptable solution. Castor can only handle "special" mapping by declaring this on the fields on the enclosing class, and cannot handle mapping types holus-bolus with special handlers. So you have to configure it with mapping files that tell Castor that ClassA with field F of EnumX uses EnumHandler. And ClassB with field F of EnumX use EnumHandler, and so on for every type that includes EnumX. You cannot configure Castor to handle all sub types of Enum with EnumHandler or even specific type EnumX with EnumHandler, not successfully in the way that we needed (i.e. every time Enum was encountered serialise it to XML using custom handler) without intervening with a mapping for every field where Enum was the type. We took several days of trying different ways of configuring Castor to arrive at the conclusion that it was unsuitable for what we had in mind.
That was last night. Enter XStream. This is how quick it took me to get a solution using Xstream. One working day.
XStream was recommended to me by Calvin Yu on the STJ mailing list after I briefly described my problem there. This morning when I got to work I downloaded XStream and got to work on it. After two hours of reading the documentation and the mailing list online this morning, I had written a Converter class for the Enum type by lunch time. I spent the rest of the afternoon fleshing out my test cases for the data we were going to serialize. I finished and committed by changes about a half hour ago, including the changes to the build in order to include Xstream in the distribution EAR.
It was stonkingly simple to achieve XML serialisation bliss with XStream. Thanks once again to XStream developers for saving my project's schedule, my schedule, and my general mental health which had degraded this week due to Castor hassle. Regards and big up!
Previous Topic
