The previous tip in this series discussed the XML handling classes in the Java standard edition known as JAXP, the Java API for XML Processing. Now I am going to look at two popular alternatives and explain why some Java programmers prefer them.
JDOM as a substitute for DOM
The originators of the JDOM project, Jason Hunter and Brett McLaughlin, felt that the W3C programming API for the Document Object Model, or DOM, as used in the JAXP toolkit, was "ridiculously complex" and used programming idioms that were uncomfortable for most programmers. The design objective for JDOM was to make it easy to accomplish the most common tasks when reading and creating XML while making maximum use of familiar Java features. After serveral years of development version 1.0 of JDOM was released in 2004.
JDOM uses Java objects and is thus specific to Java rather than the generalized definition of the org.w3c.dom interfaces. However, JDOM is not a complete substitute for JAXP. It does not contain a parser, but uses any SAX parser that is compatible with the JAXP API. Furthermore, features are provided which let JDOM code cooperate with code written to the JAXP toolkit. For example, there are simple methods to convert a JDOM model of a document to or from a DOM model.
JDOM uses Java language features programmers are used to working with. For example, collections of XML elements can manipulated with the familiar List and Iterator interfaces. In contrast, the W3C programming model in JAXP represents a collection of Node objects with the NodeList interface which uses ungainly access methods.
In my opinion, JDOM will be most attractive to Java programmers who need to produce XML documents as quickly and simply as possible. Creation of objects representing XML elements is simple and logical, and combining elements into a complete document is straightforward. Output of a document or a portion of a document to a file, String object, or stream s...
To continue reading for free, register below or login
To read more you must become a member of SearchSOA.com
uch as a network connection is conveniently handled by the XMLOutputter class.
StAX as a substitute for SAX
When using SAX to handle an XML document, the programmer connects a class with event handler methods to the parser and hands control to the parser. For each component of the XML document the parser encounters, it calls a matching event handler method, with control returning to the parser after the event is handled. This puts the programmer in the position of always responding to external events, a programming style that many find unnatural and inconvenient. An example of the inconvenience is thatto stop the parser you have to throw an exception in an event handling method.
SAX is called a "push" parser because it pushes events to the programmer's event handling code. The intent of StAX is to reverse the control. Once a StAX parser has been created, the programmer requests the next event from it so StAX is a "pull" parser.
A request for the next event gets you a Java object that implements some extension of the XMLEvent interface. These specific interfaces serve the same function as the specific event handler methods used in SAX, they tell you what type of XML markup the parser has encountered and contain information extracted from it. For example, the SAX method startElement() is called with parameters for the name and attribute contents of the element.With StAX, the event object would implement the StartElement interface which contains methods to get at the same information.
One feature of StAX that simplifies programming is the ability to "peek" at the next event without consuming it. This lets the programmer transfer control to the most appropriate method for the waiting event. With SAX programming the method that gets an event has to deal with it immediately, there is no way to put it off. StAX offers so many advantages that a toolkit implementing StAX is expected to become part of thenext major Java version and it is currently part of Sun's Web Services Developer Pack.
Resources
JDOM version 1.0 either as compiled code or with complete source is available from the http://www.jdom.org/ site. An extended discussion with many examples can be found in Jason Hunter's book "Processing XML with Java." A proposal to incorporate JDOM in the Java standard library is being handled by JSR-102 but it does not seem to have made much progress.
The official API for StAX is defined by JSR-173, which was finalized in March 2004. A reference version is available from http://dev2dev.bea.com/xml/stax.html.
About the author
Bill Brogden is a computer consultant who enjoys exploring new technologies. He has written study guides for Java certifications and several books on using XML with Java. You can reach Bill at wbrogden@bga.com.
