JAXB Allows Customization of Class Generation

The generated Java classes are customizable using either inline annotation or
external annotation files. These external files are XML files that identify a
node of the XSD and provide additional configuration for that
node/element. In the .NET world, a similar goal is accomplished through .NET's
attribute technology. Those familiar with this .NET technology should be
able to draw parallels between the two approaches.

Example of an Inline Annotation

The subject of customizing JAXB bindings is covered in much more depth by
Sayed Hashimi in his ONJava article, "Understanding JAXB: Java Binding Customization." Architecturally, it will be illustrative
if I can show an inline annotation to add an isSet method to the XSD
that we have.

The inline bold section will instruct the JAXB binding generator to generate
a check method for setting the description property of the file class. This
scenario is similar to the null values in databases: a column in a
database can be checked not only for its value but to see if it has been set at
all.

Example of an External Annotation File

JAXB also allows extensive customization using external files as well, to
cover the cases where it is not possible or convenient to modify the XSD
document. Here is an example of an external file that does the same thing as
the above XSD annotation.

I have included just the relevant section for the description node. For the
actual file syntax look in the JAXB\samples\ subdirectory in the JAXB
distribution.

One can also alter the original XSD to suit the needs of customization. This
aspect is also covered in some detail in the above-mentioned article. These
issues are architecturally significant, as one can get a sense of how JAXB works
from a high-level perspective.

What Can Be Customized?

Now we know that JAXB can be customized, let us examine what aspects can be
customized. Package names can be customized. Derivation
can be controlled, to some extent. Method generation can be customized. The
other customizable aspects include:

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.

Like many other APIs in J2EE, JAXB is designed so that there can be more than
one implementation that adheres to the same defined interface. JAXB also
provides a range of validation services whereby the structure of XML and Java
objects can be directly checked against a schema document. JAXB also seems to
have been well thought out, offering multiple input and output mechanisms that include
input/output streams, URLs, DOM, SAX, and javax.xml.transform.SAX.SAXSource.
Whether you like it or not, JAXB uses a factory-based approach to create Java
objects that are capable of working with XML. JAXB also allows the manipulation
of the marshaller to tweak the XML output.

Programming Example Using JAXB

Let me show you a client program using the JAXB-generated Java classes.

A JAXB client typically works with three objects: context, marshaller, and unmarshaller.
The process is quite straightforward and easy. Nevertheless, obtaining the
JAXBContext is quite fishy. Actually, getting provider classes for a given API throughout the J2EE 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.

Also notice how we have to use the ObjectFactory to obtain the instances of
the Java classes. In addition, we have to use a series of set methods to populate
these objects. A constructor would have been better for mandatory arguments. But
JAXB being interface-centric, this is not really possible. Let us take a look at
how .NET does the same thing.

One main difference is that you can instantiate .NET objects directly without any factories. You can add constructors for mandatory arguments. One odd
thing with .NET is that it uses arrays. This requires a workaround for
populating child objects. JAXB has a better approach, where they use dynamic
list objects. But otherwise, the .NET's approach is much more coder-friendly and
fairly separated from the XSD requirement, making code more central. In JAXB,
XSD is more central to the process.