November 25, 2003
The JAXB spec attempts to fill an important niche in the Java world: it provides binding between XML and Java. However, in many ways, JAXB 1 fails to live up to its charter, which is to provide a standard, reliable, and usable binding of XML Schema to Java. The structure of the JAXB specification prohibits full implemetation of the W3C XML Schema standard, and it also fails to define rules that reliably provide robust and easy-to-use Java bindings. I am serving on the JAXB 2 expert group to try to help remedy the situation, but my advice to people now is: avoid JAXB 1.
Alternatives to JAXB
Of course, as the original designer of the open-source XMLBeans project (currently in incubation in Apache), I am particularly sensitive to the shortcomings of JAXB. On the XMLBeans development team we have considered - and several times have decided to reject - the proposal of implementing the JAXB standard. We are considering it again now, but at best, we may be able to implement JAXB as an add-on that provides a weak alternative to the more solid full XML Schema binding in XMLBeans. In reality, other than issues related to the marketing value of Sun branding, there are few reasons to use JAXB today.
Why hasn't XMLBeans just implemented JAXB? The problem is that the JAXB 1.0 standard has gotten (borrowing a turn of phrase from a colleague from another company) a bit lost in the weeds. It is a large and complicated specification that prevents you from implementing the also-large-and-complicated XML Schema specification. Given the fact that the very reason you use XML is to interoperate with other systems that you do not control, I'd take 100% XML Schema support over JAXB support any day of the week. The problem, of course, is that by only supporting a portion of XML Schema, JAXB prevents you from integrating with systems if they happen to use particular kinds of schemas. If deep inside a schema you find some data that you cannot access, then you will end up regretting having committed yourself to your binding framework.
When you use a tool to help achieve compatibility with data formats that are out of your control, 80% support is not useful. Even 99% is often insufficient. For you to solve real integration problems on top of a binding framework, you need to have reliable access to 100% of your data, 100% of the time.
The Three Basic JAXB Problems
The problems with JAXB began when the JSR 31 expert group decided that they did not want to attempt full compatibility with the XML Schema standard. It is explicitly not a goal of JAXB to support all of Schema - they even have a list of key Schema constructs which they explicitly do not require. The expert group tried to assuage themselves by assuring, in the specification, that although all of XML Schema was not required, it would be permitted.
However, like any complicated software engineering effort, if it is not part of the design, it is not going to happen by itself. By defining how to bind a fairly small subset of XML Schema, JAXB left out of consideration several major features of XML Schema, and as a result ended up putting in place design requirements that make it impossible to support those major Schema features.
What is missing from the JAXB specification? It suffers from three main problems.
To Be Continued
This entry originally continued on here, but Cedric correctly pointed out that the details were getting long, and I should take my time. This is a new weblog, after all.
So in the next few days I will explain the details of the three basic problems facing JAXB. My hope is that the discussion will help us along in figuring out how to fix the problems in future versions of the standard.Posted by David at November 25, 2003 02:27 PM
|Copyright 2003 © David Bau. All Rights Reserved.|