Experiences with JAXB
When our team looked into a solution for processing XML messages, JAXB seemed like an obvious choice, as it is part of the Sun J2EE infrastructure. XSDs were not an issue, as we already have XSDs for the XML messages that we deal with. These XSDs are fairly complex. We are quite pleased with the JAXB handling of our XSDs. JAXB also seems to process the XML messages quite efficiently. JAXB is also found to be quite reliable.
XSDs being such an integral assumption of JAXB, the validation of data structures against an XSD is quite strong and a useful element in the solution. The documentation of JAXB also goes on to say that one can use the RelaxNG syntax for schemas via an available extension.
My Impressions of JAXB
Although the team is quite pleased with JAXB, I see some issues with JAXB for broader architectures. At the outset, JAXB requires a schema document (at least in the current release). This means you cannot take an XML document and try to map it into a similarly structured Java class. More importantly, these Java classes need to be generated by JAXB. This is because the serialization and unserialization are accomplished through JAXB's hidden implementation classes and not through reflection. This approach might be more efficient, but from a maintenance and expediency perspective, this solution doesn't fare very well.
JAXB prides itself on allowing for multiple implementations. I am not sure if this requirement hasn't stretched JAXB to be more complex than it needs to be. This idea resulted in interfaces and implementations for the binding generated classes. This makes it hard to change the generated classes — they're usually not touchable for any modifications. So the final authority is the XSDs and not the java classes. Another consequence of this approach is that the generated classes are more numerous and more complex compared to .NET's binding approach.
Due to the nature of the interfaces, one cannot
new content objects:
you have to use a factory. This can be very tedious, as your content hierarchy
involves getting new objects all the time. For every object creation you have to go to the factory.
The validations and extensions to the default behavior are a bit complex. For example the inline annotations and external annotation files for customizing binding are a bit more complex than .NET. Given that Java 1.3 does not have support for meta attributes this may be the only reasonable solution.
What Are Others Saying About JAXB?
Architecturally, it is also worth noting the sentiments of others on the subject of JAXB. The primary complaint with JAXB seems to be the mandatory reliance on the W3C schema in the current release. For instance, in .NET, you can take an arbitrary C# object and serialize it as XML. The object doesn't have to be generated from a schema. Even though the original object may have been generated from the schema, you can tweak the object, add a couple of fields, and serialize it as XML.
The second problem is the nature of the code generated by JAXB. JAXB
generates interfaces representing the content (domain) objects. This
means when it is time to create the object tree, you can't just
instantiate these objects. You have to use the
ObjectFactory created by
JAXB to create each new object. This can be a bit tedious compared to
creating other objects with a typical
As I said, JAXB generates interfaces that you can't change or touch
-- if you do, then the implementations will be out of whack. It is
almost as if these generated classes are untouchable. Any necessary changes
have to be made to the XSDs, and changing XSDs is not
necessarily child's play. Perhaps with the help of
xmlspy this might be easy enough. But changes to XSDs can result in different styles of Java code generation. For simple tweaks, this seems to be a
heavy-handed approach. That said, ne can also argue that the JAXB approach is
better, as the "truth" is always maintained in one place: the XSD file.
There is one more issue with the generated interfaces. It might be minor, but it's worth mentioning: because of the
set methods of the interfaces, the interface definitions tend to be verbose, clouding the structure of the data (not to mention bloating the size of the generated code). In contrast, .NET produces classes with public properties.
Although one could argue with the sanity of public properties, the approach
has a practical advantage to it: clarity.
Although the architecture of interfaces, implementations, and multiple providers is seen in general as an advantage the resulting solution seem to be unnecessarily complex for general usage. Perhaps this is a difficult point to argue as perhaps JAXB might come out to be wiser in the long run for the provided flexibility.
In general, the XML binding infrastructure in the Java space seem to be much more diversified and involved compared to .NET's approach. Having worked with both .NET's XML binding and JAXB's binding, .NET seem to be lot more easier and cleaner for the simpler and straightforward cases. Nevertheless, I am not sure how they fare in cases with complex and more flexible requirements.
JAXB and Castor seemed to be the primary contenders in the Java space until recently. With the recent release and inclusion of JAXB into the web services pack, I believe more and more people are going to be using JAXB. Also once one accepts the fact that they have to work with XSDs to work with JAXB (for now) one can always find workarounds for existing Java classes.
As pointed out in the "Experiences with JAXB" section, it seems to be stable, reliable and usable for day-to-day operations. A few of my colleagues, Sayed Hashimi and David Goyette, have used JAXB extensively for XML message processing and also for configuration files. Their feedback is that both are quite thrilled with the results and their lives are lot easier now with JAXB, compared to their earlier use of a SAX parser for the same project.
Nevertheless, it pays to know the following while working with JAXB:
- Working knowledge of XSD
- A tool such as
xmlspyto work with XML and XSD
- Working knowledge of Ant scripts
- The sample directory that is distributed with JAXB
- Online JAXB question/answer forum at Sun
- JAXB home page for articles, what's new, and JAXB packaging information
- JAXB Executive summary from Sun
- The JAXB API
This article by Kohsuke Kawaguchi explains the overview, architecture and potential limitations of JAXB. This is a good read.
- "Java architecture for XML binding"
This is the next-level reading from the executive summary from Sun. It has some sample code identifying the key features, but doesn't have the sample code that might be complete enough for you to be productive.
- JAXB RI RELAX NG extension
Supposedly a better way to deal with XML and Java. The reader is advised to do further research.
- XML Knowledge Folder
As XSDs are so crucial to work with JAXB, this above link has a collection of resources that will help with XML-related technologies (including authoring basic XSDs) to get you started on JAXB.
Return to ONJava.com.