Learning Java, 4th Edition

SAX

SAX is a low-level, event-style API for parsing XML documents. SAX originated in Java, but has been implemented in many languages. We’ll begin our discussion of the Java XML APIs here at this lower level, and work our way up to higher-level (and often more convenient) APIs as we go.

The SAX API

To use SAX, we’ll draw on classes from the org.xml.sax package, standardized by the W3C. This package holds interfaces common to all implementations of SAX. To perform the actual parsing, we’ll need the javax.xml.parsers package, which is the standard Java package for accessing XML parsers. The java.xml.parsers package is part of the Java API for XML Processing (JAXP), which allows different parser implementations to be used with Java in a portable way.

To read an XML document with SAX, we first register an org.xml.sax.ContentHandler class with the parser. The ContentHandler has methods that are called in response to parts of the document. For example, the ContentHandler’s startElement() method is called when an opening tag is encountered, and the endElement() method is called when the tag is closed. Attributes are provided with the startElement() call. Text content of elements is passed through a separate method called characters(). The characters() method may be invoked repeatedly to supply more text as it is read, but it often gets the whole string in one bite. The following are the method signatures of these methods of the ContentHandler class.

public void startElement(
    String namespace, String localname, String qname, Attributes atts );
public void characters(
    char[] ch, int start, int len );
public void endElement(
    String namespace, String localname, String qname );

The qname parameter is the qualified name of the element: this is the element name, prefixed with any namespace that may be applied. When you’re working with namespaces, the namespace and localname parameters are also supplied, providing the namespace and unqualified element name separately.

The ContentHandler interface also contains methods called in response to the start and end of the document, startDocument() and endDocument(), as well as those for handling namespace mapping, special XML instructions, and whitespace that is not part of the text content and may optionally be ignored. We’ll confine ourselves to the three previous methods for our examples. As with many other Java interfaces, a simple implementation, org.xml.sax.helpers.DefaultHandler, is provided for us that allows us to override only the methods in which we’re interested.

JAXP

To perform the parsing, we’ll need to get a parser from the javax.xml.parsers package. JAXP abstracts the process of getting a parser through a factory pattern, allowing different parser implementations to be plugged into the Java platform. The following snippet constructs a SAXParser object and then gets an XMLReader used to parse a file:

    import javax.xml.parsers.*;
    SAXParserFactory factory = SAXParserFactory.newInstance();
    SAXParser saxParser = factory.newSAXParser();
    XMLReader reader = saxParser.getXMLReader();
    
    reader.setContentHandler( myContentHandler );
    reader.parse( "myfile.xml" );

You might expect the SAXParser to have the parse method. The XMLReader intermediary was added to support changes in the SAX API between 1.0 and 2.0. Later, we’ll discuss some options that can be set to govern how XML parsers operate. These options are normally set through methods on the parser factory (e.g., SAXParserFactory) and not the parser itself. This is because the factory may wish to use different implementations to support different required features.

SAX’s strengths and weaknesses

The primary motivation for using SAX instead of the higher-level APIs that we’ll discuss later is that it is lightweight and event-driven. SAX doesn’t require maintaining the entire document in memory. So if, for example, you need to grab the text of just a few elements from a document, or if you need to extract elements from a large stream of XML, you can do so efficiently with SAX. The event-driven nature of SAX also allows you to take actions as the beginning and end tags are parsed. This can be useful for directly manipulating your own models without first going through another representation. The primary weakness of SAX is that you are operating on a tag-by-tag level with no help from the parser to maintain context. We’ll talk about how to overcome this limitation next. Later, we’ll also talk about the new XPath API, which combines much of the benefits of both SAX and DOM in a form that is easier to use.

Building a Model Using SAX

The ContentHandler mechanism for receiving SAX events is very simple. It should be easy to see how one could use it to capture the value or attributes of a single element in a document. What may be harder to see is how one could use SAX to populate a real Java object model. Creating or pushing data into Java objects from XML is such a common activity that it’s worth considering how the SAX API applies to this problem. The following example, SAXModelBuilder, does just this, reading an XML description and creating Java objects on command. This example is a bit unusual in that we resort to using some reflection to do the job, but this is a case where we’re trying to interact with Java objects dynamically.

In this section, we’ll start by creating some XML along with corresponding Java classes that serve as the model for this XML. The focus of the example code here is to create the generic model builder that uses SAX to read the XML and populate the model classes with their data. The idea is that the developer is creating only XML and model classes—no custom code—to do the parsing. You might use code like this to read configuration files for an application or to implement a custom XML “language” for describing workflows. The advantage is that there is no real parsing code in the application at all, only in the generic builder tool. Finally, late in this chapter when we discuss the more powerful JAXB APIs, we’ll reuse the Java object model from this example simply by adding a few annotations.

Creating the XML file

The first thing we’ll need is a nice XML document to parse. Luckily, it’s inventory time at the zoo! The following document, zooinventory.xml, describes two of the zoo’s residents, including some vital information about their diets:

<?xml version="1.0" encoding="UTF-8"?>
    <inventory>
        <animal animalClass="mammal">
            <name>Song Fang</name>
            <species>Giant Panda</species>
            <habitat>China</habitat>
            <food>Bamboo</food>
            <temperament>Friendly</temperament>
            <weight>45.0</weight>
        </animal>
        <animal animalClass="mammal">
            <name>Cocoa</name>
            <species>Gorilla</species>
            <habitat>Central Africa</habitat>
            <foodRecipe>
                <name>Gorilla Chow</name>
                <ingredient>fruit</ingredient>
                <ingredient>shoots</ingredient>
                <ingredient>leaves</ingredient>
            </foodRecipe>
            <temperament>Know-it-all</temperament>
            <weight>45.0</weight>
        </animal>
    </inventory>

The document is fairly simple. The root element, <inventory>, contains two <animal> elements as children. <animal> contains several simple text elements for things like name, species, and habitat. It also contains either a simple <food> element or a complex <foodRecipe> element. Finally, note that the <animal> element has one attribute, animalClass, that describes the zoological classification of the creature (e.g., Mammal, Bird, Fish, etc.). This gives us a representative set of XML features to play with in our examples.

The model

Now let’s make a Java object model for our zoo inventory. This part is very mechanical—we simply create a class for each of the complex element types in our XML; anything other than a simple string or number. Best practices would probably be to use the standard JavaBeans property design pattern here—that is, to use a private field (instance variable) plus a pair of get and set methods for each property. However, because these classes are just simple data holders and we want to keep our example small, we’re going to opt to use public fields. Everything we’re going to do in this example and, much more importantly, everything we’re going to do when we reuse this model in the later JAXB binding example, can be made to work with either field or JavaBeans-style method-based properties equivalently. In this example, it would just be a matter of how we set the values and later in the JAXB case, it would be a matter of where we put the annotations. So here are the classes:

    public class Inventory {
           public List<Animal> animal = new ArrayList<>();
    }

    public class Animal 
    {
        public static enum AnimalClass { mammal, reptile, bird, fish, amphibian,
            invertebrate }    

        public AnimalClass animalClass;    
        public String name, species, habitat, food, temperament;    
        public Double weight;
        public FoodRecipe foodRecipe;
    
        public String toString() { return name +"("+animalClass+",
            "+species+")"; }
    }

    public class FoodRecipe
    {
        public String name;
        public List<String> ingredient = new ArrayList<String>();
    
        public String toString() { return name + ": "+ ingredient.toString(); }
    }

As you can see, for the cases where we need to represent a sequence of elements (e.g., animal in inventory), we have used a List collection. Also note that the property that will serve to hold our animalClass attribute (e.g., mammal) is represented as an enum type. We’ve also throw in simple toString() methods for later use. One more thing—we’ve chosen to name our collections in the singular form here (e.g., “animal,” as opposed to “animals”) just because it is convenient. We’ll talk about mapping names more in the JAXB example.

The SAXModelBuilder

Let’s get down to business and write our builder tool. Now we could do this by using the SAX API in combination with some “hardcoded” knowledge about the incoming tags and the classes we want to output (imagine a whole bunch of switches or if/then statements); however, we’re going do better than that and make a more generic model builder that maps our XML to classes by name. The SAXModelBuilder that we create in this section receives SAX events from parsing an XML file and dynamically constructs objects or sets properties corresponding to the names of the element tags. Our model builder is small, but it handles the most common structures: nested elements and elements with simple text or numeric content. We treat attributes as equivalent to element data as far as our model classes go and we support three basic types: String, Double, and Enum.

Here is the code:

import org.xml.sax.*;
import org.xml.sax.helpers.*;
import java.util.*;
import java.lang.reflect.*;

public class SAXModelBuilder extends DefaultHandler
{
    Stack<Object> stack = new Stack<>();

    public void startElement( String namespace, String localname, String qname,
        Attributes atts ) throws SAXException
    {
        // Construct the new element and set any attributes on it
        Object element;
        try {
            String className = Character.toUpperCase( qname.charAt( 0 ) ) +
                qname.substring( 1 );
            element = Class.forName( className ).newInstance();
        } catch ( Exception e ) {
            element = new StringBuffer();
        }

        for( int i=0; i<atts.getLength(); i++) {
            try {
                setProperty( atts.getQName( i ), element, atts.getValue( i ) );
            } catch ( Exception e ) { throw new SAXException( "Error: ", e ); }
        }

        stack.push( element );
    }

    public void endElement( String namespace, String localname, String qname )
        throws SAXException
    {
        // Add the element to its parent
        if ( stack.size() > 1) {
            Object element = stack.pop();
            try {
                setProperty( qname, stack.peek(), element );
            } catch ( Exception e ) { throw new SAXException( "Error: ", e ); }
        }
    }

    public void characters(char[] ch, int start, int len )
    {
        // Receive element content text
        String text = new String( ch, start, len );
        if ( text.trim().length() == 0 ) { return; }
        ((StringBuffer)stack.peek()).append( text );
    }

    void setProperty( String name, Object target, Object value )
        throws SAXException, IllegalAccessException, NoSuchFieldException
    {
        Field field = target.getClass().getField( name );

        // Convert values to field type
        if ( value instanceof StringBuffer ) {
            value = value.toString();
        }
        if ( field.getType() == Double.class ) {
            value = Double.parseDouble( value.toString() );
        }
        if ( Enum.class.isAssignableFrom( field.getType() ) ) {
            value = Enum.valueOf( (Class<Enum>)field.getType(),
                value.toString() );
        }

        // Apply to field
        if ( field.getType() == value.getClass() ) {
            field.set( target, value );
        } else
        if ( Collection.class.isAssignableFrom( field.getType() ) ) {
            Collection collection = (Collection)field.get( target );
            collection.add( value );
        } else {
            throw new RuntimeException( "Unable to set property..." );
        }
    }

    public Object getModel() { return stack.pop(); }
}

The code may be a little hard to digest at first: we are using reflection to construct the objects and set the properties on the fields. But the gist of it is really just that the three methods, startElement(), characters(), and endElement()‚ are called in response to the tags of the input and we store the data as we receive it. Let’s take a look.

The SAXModelBuilder extends DefaultHandler to help us implement the ContentHandler interface. Because SAX events follow the hierarchical structure of the XML document, we use a simple stack to keep track of which object we are currently parsing. At the start of each element, the model builder attempts to create an instance of a class with the same name (uppercase) as the element and push it onto the top of the stack. Each nested opening tag creates a new object on the stack until we encounter a closing tag. Upon reaching an end of an element, we pop the current object off the stack and attempt to apply its value to its parent (the enclosing XML element), which is the new top of the stack. For elements with simple content that do not have a corresponding class, we place a StringBuffer on the stack as a stand-in to hold the character content until the tag is closed. In this case, the name of the tag indicates the property on the parent that should get the text and upon seeing the closing tag, we apply it in the same way. Attributes are applied to the current object on the stack within the startElement() method using the same technique. The final closing tag leaves the top-level element (inventory in this case) on the stack for us to retrieve.

To set values on our objects, we use our setProperty() method. It uses reflection to look for a field matching the name of the tag within the specified object. It also handles some simple type conversions based on the type of the field found. If the field is of type Double, we parse the text to a number; if it is an Enum type, we find the matching enum value represented by the text. Finally, if the field is not a simple field but is a Collection representing an XML sequence, then we invoke its add() method to add the child to the collection instead of trying to assign to the field itself.

Test drive

Finally, we can test drive the model builder with the following class, TestSAXModelBuilder, which calls the SAX parser, setting an instance of our SAXModelBuilder as the content handler. The test class then prints some of the information parsed from the zooinventory.xml file:

    import org.xml.sax.*;
    import javax.xml.parsers.*;
    
    public class TestSAXModelBuilder
    {
        public static void main( String [] args ) throws Exception
        {
            SAXParserFactory factory = SAXParserFactory
                .newInstance();
            SAXParser saxParser = factory.newSAXParser();
            XMLReader parser = saxParser.getXMLReader();
            SAXModelBuilder mb = new SAXModelBuilder();
            parser.setContentHandler( mb );
    
            parser.parse( new InputSource("zooinventory.xml") );
            Inventory inventory = (Inventory)mb.getModel();
            System.out.println("Animals = "+inventory.animal);
            Animal cocoa = (Animal)(inventory.animal.get(1));
            FoodRecipe recipe = cocoa.foodRecipe;
            System.out.println( "Recipe = "+recipe );
        }
    }

The output should look like this:

Animals = [Song Fang(mammal, Giant Panda), Cocoa(mammal, Gorilla)]
Recipe = Gorilla Chow: [fruit, shoots, leaves]

In the following sections, we’ll generate the equivalent output using different tools.

Limitations and possibilities

To make our model builder more complete, we could use more robust naming conventions for our tags and model classes (taking into account packages and mixed capitalization, etc.). More generally, we might want to introduce arbitrary mappings (bindings) between names and classes or properties. And of course, there is the problem of taking our model and going the other way, using it to generate an XML document. You can see where this is going: JAXB will do all of that for us, coming up later in this chapter.

XMLEncoder/Decoder

Java includes a standard tool for serializing JavaBeans classes to XML. The java.beans package XMLEncoder and XMLDecoder classes are analogous to java.ioObjectInputStream and ObjectOutputStream. Instead of using the native Java serialization format, they store the object state in a high-level XML format. We say that they are analogous, but the XML encoder is not a general replacement for Java object serialization. Instead, it is specialized to work with objects that follow the JavaBeans design patterns (setter and getter methods for properties), and it can only store and recover the state of the object that is expressed through a bean’s public properties in this way.

When you call it, the XMLEncoder attempts to construct an in-memory copy of the graph of beans that you are serializing using only public constructors and JavaBean properties. As it works, it writes out the steps required as “instructions” in an XML format. Later, the XMLDecoder executes these instructions and reproduces the result. The primary advantage of this process is that it is highly resilient to changes in the class implementation. While standard Java object serialization can accommodate many kinds of “compatible changes” in classes, it requires some help from the developer to get it right. Because the XMLEncoder uses only public APIs and writes instructions in simple XML, it is expected that this form of serialization will be the most robust way to store the state of JavaBeans. The process is referred to as long-term persistence for JavaBeans.

It might seem at first like this would obviate the need for our SAXModelBuilder example. Why not simply write our XML in the format that XMLDecoder understands and use it to build our model? Although XMLEncoder is very efficient at eliminating redundancy, you would see that its output is still very verbose (about two to three times larger than our original XML) and not very human-friendly. Although it’s possible to write it by hand, this XML format wasn’t designed for that. Finally, although XMLEncoder can be customized for how it handles specific object types, it suffers from the same problem that our model builder does, in that “binding” (the namespace of tags) is determined strictly by our Java class names. As we’ve said before, what is really needed is a more general tool to map our own classes to XML and back.