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:
- users guide
- sample apps
- sample source code
- Uses xml schemas
- Bindings are customizable using three ways
- Variations in authoring XSD
- Inline Annotations
- External Annotation files
- Customizable aspects include
- Creating tests to see if a property has been set or not (to accomodate such things as database nulls)
- Name the package, derived classes, and methods
- Assign types to the methods within the derived classes
- Choose which elements to bind to classes
- Decide how to bind each attribute and element declaration to a property in the appropriate content class
- Choose the type of each attribute-value or content specification
- Provides for multiple implementationsj by various providers
- Client API is indenpendent of an implementation for portability
- Validate source xml tree against an xsd
- Unmarshal from sources other than input xml files. These sources include
- SAX events
- Provides a way to create content objects via a factory
- You can tell the marshaller to generate ouput in a variety of fashions
Good things about JAXB
- We managed to work with complex XSDs created by XML spy with out a problem
- Doesn't seem to be slow
- Latest version is very reliable
- Good validation support for adhering to the XSDs
- Can use RelaxNG syntax for schemas (available as an extension)
Known issues with JAXB as I see
- Jaxb requires xml schema to work with
- There are some issues with dates but there are work arounds
- A full specification for binding might be an overkill with multiple implementations compared to .Net's approach of one solution fits all
- Generates interface classes with no access to implementations
- Compared to .net it is much harder to know the structure of java classes
- Validations and extensions to the base behavior is a bit complex
- The generated classes are untouchable
- Can't new content objects. You have to use a factory. This can be very tedious as your content hierarchy involves setting new objects all the time. For every creation you have to go to the factory.
Some of these issues are discussed in the following chapter.
What are others saying about JAXB
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".
Convert XML to Java (Unmarshall)
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.
Convert Java to XML (Marshall)
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:
2. Jaxb home page:
Contains 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. 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
Supposedly a better way to deal with XML and Java. The reader is advised to do further research.