Sign In/My Account | View Cart  

advertisement

AddThis Social Bookmark Button

Listen Print Discuss

The State of JAXB: Availability, Suitability, Analysis, and Architecture
Pages: 1, 2, 3, 4

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 new.

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 get/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.

Bottom Line

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 xmlspy to work with XML and XSD
  • Working knowledge of Ant scripts
  • The sample directory that is distributed with JAXB

References

  1. Online JAXB question/answer forum at Sun
  2. JAXB home page for articles, what's new, and JAXB packaging information
  3. JAXB Executive summary from Sun
  4. The JAXB API
    This article by Kohsuke Kawaguchi explains the overview, architecture and potential limitations of JAXB. This is a good read.
  5. "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.
  6. JAXB RI RELAX NG extension
    Supposedly a better way to deal with XML and Java. The reader is advised to do further research.
  7. 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.

Satya Komatineni is the CTO at Indent, Inc. and the author of Aspire, an open source web development RAD tool for J2EE/XML.

Return to ONJava.com.