JAXB

At the time of writing this tutorial, the JAXB specifications were public draft version 0.75 and Reference Implementation 1.0. We do not anticipate significant changes between these and the FCS.

The Need for Binding and JAXB

In , we introduced the concept of parsing XML using SAX and DOM. However, we also mentioned that this would not be necessary, because developers will work with JAXB. Let us now expand on this. The traditional design approach when dealing with XML in app code has centered around retrieval and parsing of XML, using XML parsers and API (such as JAXP and SAX/DOM) and manipulating the result of that parsing exercise. For example, with SAX, developers run though an XML file in a serial manner, access data, and use its programmatic representation-their own Java objects. Alternatively, developers parse the XML using a tree-based approach and create object tree representations in memory, using a model defined by some other party (e.g., the W3C DOM) or JDOM. In either case, there is a disconnect between the XML data definitions.

For example, the purchase order used in Listing 11.5 is represented by an XML schema shown in Listing 13.1. The schema was not listed earlier for brevity but is included with the example code.Listing 13.1: The purchaseorder.xsd schema from Chapter 9

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="http://www.flutebank.com/schema" xmlns:xsd="http://
www.w3.org/2001/XMLSchema" xmlns="http://www.flutebank.com/schema" elementFormDefault=
"qualified">
 <xsd:element >
 <xsd:complexType>
 <xsd:sequence>
 <xsd:element ref="name"/>
 <xsd:element ref="street"/>
 <xsd:element ref="city"/>
 <xsd:element ref="state"/>
 <xsd:element ref="zip"/>
 </xsd:sequence>
 </xsd:complexType>
 </xsd:element>
 <xsd:element type="xsd:string"/>
 <xsd:element type="xsd:string"/>
 <xsd:element type="xsd:string"/>
 <xsd:element type="xsd:string"/>
 <xsd:element >
 <xsd:complexType>
 <xsd:sequence>
 <xsd:element ref="quantity"/>
 <xsd:element ref="productnumber"/>
 <xsd:element ref="description"/>
 <xsd:element ref="unitcost"/>
 </xsd:sequence>
 </xsd:complexType>
 </xsd:element>
 <xsd:element >
 <xsd:complexType>
 <xsd:sequence>
 <xsd:element ref="item" maxOccurs="unbounded"/>
 </xsd:sequence>
 </xsd:complexType>
 </xsd:element>
 <xsd:element type="xsd:string"/>
 <xsd:element type="xsd:string"/>
 <xsd:element >
 <xsd:complexType>
 <xsd:sequence>
 <xsd:element ref="identifier"/>
 <xsd:element ref="date"/>
 <xsd:element ref="billingaddress"/>
 <xsd:element ref="items"/>
 </xsd:sequence>
 </xsd:complexType>
 </xsd:element>
 <xsd:element type="xsd:int"/>
 <xsd:element type="xsd:string"/>
 <xsd:element type="xsd:string"/>
 <xsd:element type="xsd:decimal"/>
 <xsd:element type="xsd:string"/>
</xsd:schema>

SML schemas are explained briefly in Appendix A for those readers who are unfamiliar with them.

To pass this logical collection of data around in their code, developers often define a Java class that wraps the data into a JavaBean-type construct, with get/set methods or the attributes. However, the class is developer-designed and -defined and is therefore based on the developer's interpretation of the XML schema. For example, based on the schema in Listing 13.1, a developer may create an Item bean as follows:

package com.jwsa.mybeans;
public class Item {
 private String Quantity;
 private String Productnumber;
 private String Description;
 private String Unitcost;
 public String getQuantity() {
 return Quantity;
 }
 public void setQuantity(String quantity) {
 Quantity = quantity;
 }
 public String getProductnumber() {
 return Productnumber;
 }
 public void setProductnumber(String productnumber) {
 Productnumber = productnumber;
 }
 public String getDescription() {
 return Description;
 }
 public void setDescription(String description) {
 Description = description;
 }
 public String getUnitcost() {
 return Unitcost;
 }
 public void setUnitcost(String unitcost) {
 Unitcost = unitcost;
 }
}

Another developer may create another class with a completely different representation or even a different hierarchy. Both would parse the corresponding XML, validate it against the schema, populate their Item bean (or whatever other representation they define), and use it in the code. This approach has issues.

• It requires manual effort and extra coding.

• Any change in the schema requires changes to Java code, reducing the inherent flexibility of using XML in an app.
• It produces code that may vary from developer to developer.
• The programmatic representation may be inaccurate.
• The code is not portable, because of developer interpretation. Two apps using the same XML schema may end up using completely different PurchaseOrder objects that are mutually incompatible.
• To generate the XML representation back from the object representation, developers have to write extra code. For example, developers frequently include a toString() method in their objects (e.g., PurchaseOrder) that creates an XML string conformant to the schema based on the object properties.

JAXB aims at resolving these issues by giving developers a standard API to program to and automating the Java-XML marshalling and XML-Java unmarshalling with round-trip support between XML and Java.

Recall from that marshalling is the process of creating the XML representation from Java objects-that is, Java-XML-and the reverse process is called unmarshalling.