Created as a grassroots movement in the Java developer community, JDOM quickly acquired Java Specification Request status -- the process by which a Java project is officially made a Sun specification -- as JSR-102, guaranteeing future support for it among vendors and in wider Java circles.
Before JDOM, Java developers used either DOM or SAX for processing XML. DOM is based on the core architecture defined by the W3C DOM specification, while SAX was created by David Megginson, and is now an open source project hosted on SourceForge.
A wealth of products adhere to these methods, ranging from XML parsers like Xerces, produced by the Apache foundation, to functionalities included in the core JDK/J2SE distributed by Sun Microsystems. However, even though DOM and SAX are widely used in mainstream projects, they were not designed with the Java language in mind.
DOM, the more widely adopted technology, uses an architecture that is not even XML-centric, let alone Java-friendly. It is widely used in browser -- client-side -- development. DOM loads a data fragment -- XML or other -- into memory for later inspection or transversal by specific functions, a mechanism which is very deficient when an extensive document needs to be processed.
SAX, on the other hand, uses an event-driven model in which each XML element within a document is processed on a first-come/first-processed approach. It inspects each data node as it is presented within the structure. But even though SAX's first implementation was Java-based, its shortcomings are evident when trying to traverse XML elements, although, to SAX's benefit, JDOM builds on this form of processing, as we will see in a moment.
Among JDOM's most prominent features to a Java user are its usage of the Java Collections Framework -- a JDK/J2SE standard for aggregating objects -- for traversing XML elements, its special provisions for allowing integration with legacy DOM and SAX code, and its simple syntax for processing XML fragments, as is shown in the following snippet:
// The following code is based on classes from the following libraries // org.jdom.*; // javax.xml.*; // Define files from file-system String doc = "myxml.xml"; String sheet = "mystylesheet.xsl"; // Create SAXBuilder and Document instance for loading XML document SAXBuilder builder = new SAXBuilder(); Document tree = builder.build(doc); // Create XSLTransformer and Document instance for loading XSL stylesheet XSLTransformer transformer = new XSLTransformer(sheet); Document tree2 = transformer.transform(tree); // Output the tree to the console XMLOutputter out = new XMLOutputter(Format.getPrettyFormat()); out.output(tree2, System.out);
This fragment of code takes an XML document and applies to it an XSL style sheet, transforming the data into a newly formatted XML page. The initial step consists of creating both a
Document instance to hold the XML document. Notice how this process takes only two lines of code, without any need to create I/O classes or DOM/SAX functions explicitly. The second step loads the XSL style sheet from the filesystem with an
XSLTransformer instance and applies it to the initial XML document through the
transform() function of the aforementioned class, and the result is assigned to a second
The transformed XML is finally sent to the console with the
output function of the
XMLOutputter class. Although this is a terminal driven example, the same JDOM functionalities can be used -- just like SAX or DOM -- in any other XML-driven Java application, such as JSP's Servlets or Web services, giving developers a simple, concise approach to navigating XML data.
Daniel Rubio is the principal consultant at Osmosis Latina, a firm specializing in enterprise software development, training, and consulting based in Mexico.