There is little doubt that objects provide distinct advantages when working in Java compared to SAX, DOM, or raw XML. But in Java the problem or facility is that there are so many alternatives available for binding Java and XML. In .Net this choice is made for you by Microsoft in terms of a tool called XSD.exe. Of the solutions available in Java, Jaxb seem to have finally turned the corner and is now part of the web services developer pack.
This article examines the current state of jaxb based on literature available on the internet. This article will examine the following to answer the question of "what is the state of Jaxb and will I choose it for my development effort?".
Jaxb Packaging
Jaxb features
Good things about JAXB
Known issues with JAXB as I see
What are others saying about JAXB
Bottomline
Samplecode: A taste of jaxb
Generate java classes from XSDs
XML to Java
Java to XML
References
JAXB is part of Java Web Services Developer pack 1.x. This integrated toolkit contains all of J2EE's xml technologies including sax, dom, webservices etc. The included jaxb includes the following:
Some of these issues are discussed in the following chapter.
The primary item seem 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 and 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 when you could have hoped for a direct new operation.
As I said jaxb generates interfaces that you can't change or touch. If you do that then the implemenations will be out of whack. It is almost like these generated classes are untouchable. Any changes has to be made to the XSDs. Now changing XSDs is not necessarily a 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 seem to be an overhanded approach. One can also argue that the Jaxb approach is better as the truth is always maintained in one place which is the XSD.
There is one more issue with the generated interfaces. This might be minor but 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 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 sense 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 complex for the general usage. Perhaps this is a difficult one to argue on 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 lot more diversified and involved compared to .net's approach. I personally have worked in .net's xml binding and Jaxb's binding. For the simpler and straightforward cases .net seem to be lot more easier and cleaner. Nevertheless I am not sure how they fare in case of complex flexible requirements.
In the java space until recently Jaxb and Castor seem to be the primary conenders. With the recent release and inclusion of jaxb into the webservices 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 "Good things about jaxb" section it seem to be stable, reliable and usable for day to day operations. A few of my colleagues Sayed Hashimi, and David Goyette has used it extensively for XML message processing and also for configuration files. The feedback is that both are quite thrilled with the results and their life is lot easier now with jaxb (Earlier a SAX parser was used for the same project).
The following sample code is extracted from "Architecture for XML Binding (JAXB) by Ed Ort and Bhakti Mehta, March 2003" to show you a taste of how jaxb coding look like with some of my own comments pepperred in.
xjc.sh -p test.jaxb books.xsd -d work
From books.xsd generate required interfaces and implementations in a package called "test.jaxb" and place it in a directory called "work".
import javax.xml.bind.*;
//Get the context to work on
JAXBContext jc = JAXBContext.newInstance("test.jaxb");
Unmarshaller unmarshaller = jc.createUnmarshaller();
//The following is a generated test.jaxb.Collection
Collection collection= (Collection)
unmarshaller.unmarshal(new File( "books.xml"));
//Using the object
CollectionType.BooksType booksType = collection.getBooks();
List bookList = booksType.getBook();
//Write the object back to xml
Marshaller marshaller = jc.createMarshaller();
marshaller.marshall(collection,
new FileOutputStream("jaxbOutput.xml"));
As a JAXB client there are mainly three objects. Context, marshaller, and unmarshaller. The process is quite starightforward and easy. Nevertheless obtaining the JAXBContext is quite fishy. Through out the J2EE API getting provider classes for a given API is quite inconsistent. In this case you have to pass the package names to the static function of "newInstance" to locate the provider for the "JAXBContext". Passing package names for locating implementation objects seem odd. I have read the explanations in the java api for it. I am not convinced if this is the best way to obtain an implementation for a given interface.
ObjectFactory objFactory = new ObjectFactory();
//Create object shells
Collection collection=
(Collection) objFactory.createCollection();
Collection.BooksType booksType = objFactory.
createCollectionTypeBooksType();
BookType book = objFactory.createBookType();
//set data items
book.setItemId("307");
book.setName("JAXB today and beyond");
//Validate collection (optional. If needed)
Validator validator = jaxbContext.createValidator();
validator.validate(collection));
//get a marshaller
Marshaller marshaller = jaxbContext.createMarshaller();
//specify output behavior
marshaller.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT,
new Boolean(true));
//write out xml
marshaller.marshal(collection,
new FileOutputStream("jaxbOutput.xml"));
The interesting point to make by looking at this code is the nature in which objects are instantiated. This is done through an intermediate object factory and not by newing them. One of the reasons for this is that the implementations are not available to the developer and could be provider dependent.
1. To ask questions on jaxb:
http://forum.java.sun.com/forum.jsp?forum=34
2. Jaxb home page:
http://java.sun.com/xml/jaxb/index.jsp
Contains articles, what's new, and jaxb packaging information.
3. jaxb Executive summary from sun:
http://wwws.sun.com/software/xml/developers/jaxb/index.html
4. The JAXB API
http://wwws.sun.com/software/xml/developers/jaxb/index.html
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. Has some sample code identifying the key features. But it doesn't have the sample code that might be complete enough for you to be productive.
6. JAXB RI RELAX NG extension
http://java.sun.com/developer/technicalArticles/WebServices/jaxb/index.html
Supposedly a better way to deal with XML and Java. The reader is advised to do further research.