We are using JAXB as our XML-to-Java objects mapper. It is not very simple, but it does it job. However, I found significant lack of discussions about it, including here at JavaRanch. The last questions about it were asked more than a year ago. Why it is so? Does it mean that people don't care about it? Rusty Harold also did not cover it in his books. Does it mean that JAXB is bad? How people are happy with JAXB in general? Jacob Nikom
My sense is that it's not actually _bad_, but it's still pretty immature. I tried using it before the current version and ran into a lot of problems. The current version at least works, but I'd characterize it as having all the standard 1.0 type problems -- it's not terribly robust, or user friendly, or easy to incorporate into a larger solution. I think it's going to get better by leaps and bounds, and ultimately be a great help to the problem of turning XML streams into Java objects and vice versa. Nowadays that's still an awkward set of JAXP code. Just my $0.02. Ken
Recently, there�s been a flood of so-called data binding APIs that try to map XML documents into Java classes. While DOM, JDOM, and dom4j all map XML documents into Java classes, these data binding APIs attempt to go further, mapping a Book document into a Book object rather than just a generic Document object, for example. These are sometimes useful in very limited and predictable domains. However, they tend to make too many assumptions that simply aren�t true in the general case to make them broadly suitable for XML processing. In particular, these products tend to implicitly depend on one or more of the following common fallacies:
Documents have schemas or DTDs.
Documents that do have schemas and/or DTDs are valid.
Structures are fairly flat and definitely not recursive; that is, they look pretty much like tables.
Narrative documents aren�t worth considering.
Mixed content doesn�t exist.
Choices don�t exist; that is, elements with the same name tend to have the same children.
Order doesn�t matter.
The fundamental flaw in these schemes is an insistence on seeing the world through object-colored glasses. XML documents can be used for object serialization, and in that use-case all these assumptions are reasonably accurate; but XML is a lot more general than that. The large majority of XML documents cannot be plausibly understood as serialized objects, though a lot of programmers approach it from that point of view because that�s what they�re familiar with. When you're an expert with a hammer, it�s not surprising that world looks like it�s full of nails. The fact is, XML documents are not objects and schemas are not classes. The constraints and structures that apply to objects simply do not apply to XML elements and vice versa. Unlike Java objects, XML elements routinely violate their declared types, if indeed they even have a type in the first place. Even valid XML elements often have different content in different locations. Mixed content is quite common. Recursive content isn�t quite as common, but it does exist. A little more subtly, though even more importantly, XML structures are based on hierarchy and position rather than the explicit pointers of object systems. It is possible to map one to the other, but the resulting structures are ugly and fragile; and you tend to find that when you�re finished what you�ve accomplished is merely reinventing DOM. XML needs to be approached and understood on its own terms, not Java�s. Data binding APIs are just a little too limited to interest me, and I do not plan to treat them in this book.
More recent versions of JAXB have fixed some but not all of these problems. It's still an API based on a very limited picture of what XML documents look like that does nto account for their full diversity.
Elliotte Rusty Harold<br />Author of <a href="http://cafe.elharo.com/web/refactoring-html/" target="_blank" rel="nofollow">Refactoring HTML</a>