Article:		The State of JAXB: Availability, Suitability, Analysis, and Architecture
Subject:		Looking for POJO serialization
Date:		2004-05-07 17:39:29
From:		johnlindwall
I've been evaluation various Java <-> XML solutions as a way to serialize existing java domain objects (containing data AND behavior) to/from XML. I started with this doc as a starting point: http://www.rpbourret.com/xml/XMLDataBinding.htm And narrowed the list down from 40+ candidates to 10 contenders: 1. Castor, looks great 2. JAXB, Strong candidate based on standardness 3. JaxMe, alternative JAXB implementation 4. Jbind, but note bad performance in XML in Java: Data binding, Part 2: Performance 5. JiBX, fairly simple, clean XML output, uses byte-code instrumentation 6. Xgen, built on Castor 7. Zeus 8. Betwixt 9. KBML (Koala Bean Markup Language), KOML (Koala Object Markup Language), marginal survivor – no schema support? 10. XMLBeans The examples I've seen of JAXB center around using an XSD as a starting point. In addition the java objects created are simple javabean-like value objects, with no behavior. I'm starting with java objects not an XSD. I'm happy to create an XSD if needed. My dream though is to take my existing graph of domain objects and "XML-enable" them using one of these technologies. Can JAXB fill this need? Can my domain objects extend the JAXB-generated classes perhaps, thus allowing me to keep my coded behavior? Or is there some other way to XML-enable my classes? Thanks!

Showing messages 1 through 3 of 3.

• Looking for POJO serialization
  2004-05-11 10:45:55  Michaelok [View]
  
  
  Here's an informative series of articles on Data Binding in case you missed it:
  
  

• Looking for POJO serialization
  2004-05-10 12:43:19  satyak [View]
  
  

  John,
  

  Thanks for a very informative post. This is the beauty and bane of java at the moment. Very inventive solutions are there all around but difficult to standardize on in an IT environment. Unfortunately at the start of the article I haven't looked into XMLEncoder. As some posters are suggesting it may not be a bad idea to look into it for simple xml documents and cases where no one is yelling out loud for an XSD. For cases where XSD is available I felt JAXB is very good over all. I have looked at Castor only briefly as JAXB is part of the standard. Unfortunately I can't answer convincingly which of the alternatives are better where XSD is not available or cumbersome to maintain. Looks like you are on the right track to look at the right tools. Perhaps you can publish your results :-) and your experiences.
  
  

  Thanks
  

  Satya
  

• Looking for POJO serialization
  2004-05-10 07:40:34  bazzargh [View]
  
  
  JAXB isn't what you're looking. It might help the author had checked the JAXB spec to see what it was designed for:
  
  http://jcp.org/en/jsr/detail?id=031
  
  "The [...] facility compiles an XML schema into one or more Java classes. These automatically-generated classes handle the translation between XML documents that follow the schema and interrelated instances of the derived classes. They also ensure that the constraints expressed in the schema are maintained as instances of the classes are manipulated."
  
  ie its not a generic XML serialization tool, its been designed to ensure that you can manipulate an XML document slavishly following all the validity constraints of the schema (eg Social Security Nos have to match a regexp, not just "setSSN(String ssn) {this.ssn=ssn}"). If you're not trying to do round-trip edits on XML, or interop based on an agreed schema, JAXB is not for you.
  
  Incidentally this is why JAXB has to use getters and setters, if you go the MS way you'll end up with data thats not been validated.
  
  Betwixt, on the other hand, is a tool aimed at doing exactly what you are trying to do.
  
  Personally, to produce data to match a schema "on the fly", I serialize using an in-house tool (for reasons that arent irrelevant here) to a "simple and obvious" XML format then transform the result with XSL to match the particular schema we need. Save us trying to handle fiddly details like 'elementFormDefault="qualified"' from the schema. We also transform on the way in. This method is dead easy but unlike JAXB it tends to be lossy - you just ser/deser the bits you want.
  
  I use java's own XMLEncoder quite a bit, but it has one *big* gotcha that stops me using it more - default values of properties don't get serialized. If this was optional it'd be just dandy.