XML API

We all know that standard Java DOM implementation by Sun, which is bundled with JDK since early eras, has certain disadvantages:

• org.w3c.dom.NodeList does not provide a common Java collections interface iterate through it.
• There are no traversal algorithms support, the only two methods are org.w3c.dom.Document#getElementById() and org.w3c.dom.Document#getElementsByTagName().

These limitations do not come out from bad model design but are the result of strict following W3C specifications. The way out is to use alternative libraries, which compensate these limitations plus provide some extra bonuses.

Framework	Xerces / W3C DOM	Electic XML (jar)	AXIOM1) (jar)	dom4j v2.x	dom4j v1.6.1 (jar)	jDOM (jar)	XOM (jar)
Implements org.w3c.dom interfaces?
Are Java5 collections enabled?
Provides interfaces for all model elements?		2)
Are model elements java.io.Serializable?
Are model elements java.lang.Cloneable?	3)
Fluent API?
Quick serialization to XML		:YES:	:YES:	:YES:	:YES:		:YES:
Quick Element.getFirstChildElement(String name)		:YES:	:YES:	:YES:	:YES:		:YES:
Quick Element.setAttribute(String name, String value)	Element#setAttribute(String, String)	:YES:	:YES:	:YES:	:YES:	:YES:	:YES:
Quick Element.setText(String)	Node#setTextContent(String)	:YES:	:YES:	:YES:	:YES:	:YES:	:YES:
Memory-efficient processing of big XML files				:YES:4)	:YES:		:YES:5)
Visitor pattern support (DOM tree traversal)			6)	:YES:	:YES:
Building from/to DOM			/	DOMReader#read(Document) / DOMWriter#write(Document)	DOMReader#read(Document) / DOMWriter#write(Document)	DOMBuilder#build(Document) / DOMOutputter#output(Document)	DOMConverter#convert(Document)/
Building from/to SAX			StAXOMBuilder#getDocument() / OMXMLReader	SAXContentHandler#createDocument() /	SAXContentHandler#createDocument() /	SAXHandler#getDocument() / SAXOutputter#output(Document)	7) / SAXConverter#convert(Document)
Building from/to StAX	XMLDOMWriterImpl via XMLOutputFactory#createXMLStreamWriter(Result) /	/ 8)	StAXBuilder#StAXBuilder(XMLStreamReader) / OMSerializable#serialize(XMLStreamWriter)	/ STAXEventWriter(XMLEventConsumer)	/ STAXEventWriter(XMLEventConsumer)	/	/
XSTL transformation (TrAX)	DOMSource, DOMResult	9)	OMSource, OMResult	DocumentSource, DocumentResult	DocumentSource, DocumentResult	JDOMSource, JDOMResult, XSLTransformer.html#transform(Document)	XSLTransform#transform(Document)10)
XPath search		:YES:11)	:YES:12)	:YES:13)	:YES:14)	:YES:15)	:YES:16)
XPath for given node				:YES:	:YES:
XML Schema Data Type support17)				:YES:	:YES:
XInclude support							:YES:
Canonical XML support							:YES:
License	GPL	EXML license (OpenSource, copyright)	Apache license	BSD licence	BSD licence	Apache license	LGPL

Personal notes:

• XMLTool:
  Provides a true fluent API on the top of W3C DOM JDK implementation. It provides you the mechanism to create, navigate and navigate DOM tree in a stateful manner.
• Digester:
  A nice lightweight solution to you define a XML-to-Java object mapping, which is based on XML pattern rules which are triggered when the given XML path is recognized.
  Designed to target divorced big XML files.
• Electic XML:
  The serialization and parsing of XML tree is included into tree model elements. This triggers the following limitations:
  • One can read/write only to String, File, OutputStream or Writer at the moment.
  • One can probably write an adapter for pull parsers (e.g. XMLEventReader), but not for push parsers (e.g. ContentHandler).
  • So there is no way to provide another version of parser that for example creates the XML tree with elements that extend the basic (e.g. I want to replace the standard Attribute implementation with mine, which extends the standard)
• AXOIM:
  This is natural AXIOM facility not to create the complete XML tree model as the pulling the elements from builder occurs when you request the needed information from the model.
• jDOM:
  If choosing between jDOM and XOM – take XOM as it is jDOM's successor.
  jDOM has no natural DOM elements class hierarchy (e.g. Document, Attribute, Element is a Node)
  Have a look at XOM vs. dom4j notes by Elliotte Rusty Harold (author of XOM and also the contributor of JDOM).
• XOM:
  The community is so limited, that nobody cares about releasing new versions of XOM into maven.
  XOM aims to enforce correctness better than JDOM/dom4j, but the API variety is lower, also because:
  • XOM has a lot of final classes and methods. This prevents the programmers to mis-us the public API, but also reduces the code re-use and functionality improvements by extending the provided classes.
  • XOM developers are very resistant to improving API, see my threads StaX/DOM/SAX-to-XOM bridge, XSLTransform class API, Serialization API, Visitor pattern

Relative links:

• dom4j comparison to other frameworks
• Benchmark of XPP2, EXML, Xerces 1/2 DOM, Xerces 1/2 DOM with deferred node expansion, dom4j, JDOM, Crimson DOM, Xerces 1/2 SAX2, Crimson SAX
• simple comparison between DOM (Xecrces in JDK 1.6), DOM4J 1.6.1 and JDOM 1.1: see archive
• What Java XML library do you recommend?
• ElectricXML chapter by Elliotte Rusty Harold.
  • Electric XML toolkit: Free and easy to use

• XStream
• JiBX
• JAXB
• Hibernate (see hibernate)
• Castor
• What is the best Java OXM library?