In this technical tip, Bill Brogden examines some alternatives to the Java API for XML Processing (JAXP). He looks at why JDOM offers a more natural programming model to Java developers than the W3C's Document Object Model (DOM). He also discusses the advantages of using "pull" parsers, such as StAX, over the SAX "push" model.

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.

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 the next major Java version and it is currently part of Sun's Web Services Developer Pack.

Read Alternatives to JAXP

http://www.xom.nu/

JAXB -- the most underdiscussed, incredibly useful API for working with XML.

I'd put JAXB as the most useful XML API I've used. It's been instrumental in implementing our web services in a simple, performant manner.

'cmon!

I am tentatively planning discussing JAXB in the context of Web Services in one of the later columns. I'm delighted to hear that you are getting good results with it.

JDOM
- http://www.jdom.org/

DOM4J
- http://www.dom4j.org/

STAX
- http://dev2dev.bea.com/xml/stax.html

JAXB
- http://java.sun.com/webservices/jaxb/
- https://jaxb.dev.java.net/

And of course, but I always preferred our own DOM API (com.tangosol.run.xml) and XmlBean binding framework ;-)

Peace,

Cameron Purdy
Tangosol Coherence: The Java Data Grid

I never understood what XML beans brought to the table except another code generation framework. It does not seem to have much "mind share" either. Seems like another Goodwill donation to Apache.

Also, why would you hold on to your own DOM API when JDOM appears to be much more successful (other than wasting resources converting)?

Cory

I never understood what XML beans brought to the table except another code generation framework. It does not seem to have much "mind share" either. Seems like another Goodwill donation to Apache.

Also, why would you hold on to your own DOM API when JDOM appears to be much more successful (other than wasting resources converting)?

Cory

I've been using JAXB since the Beta and have used castor, xmlbeans and jaxme. Of all the Schema compilers for Java I've tried, XmlBeans does provide better coverage of XML Schema specification. BEA's webservice stack uses XmlBeans I believe, so there's quite a few people using it.

peter

XStream is in a different category (marshal, unmarshal/serialization api) but it should be mentioned. It doesn't support schemas directly but you can write converters to adhere to schemas. It works with ANY java class... no compiling necessary and no restrictions are placed on the java object.

Personally, I wish XStream and JDOM were part of JSE 6. Both api's need some improvements though.

http://xstream.codehaus.org/

Xstream rules!

I totally agree with you Reeder, and would like to thank the developers of XStream team.

It is important to note that there is another category of dealing with XML as objects that does not require code generation. These are what I call the object-to-XML mapping or OXM offerings.

In a similar way that object-relational mapping (ORM) makes dealing with a database easier, OXM makes dealing with XML easier by allowing you to use your own domain objects.

When picking an OXM or code generation solution it is important to look at the following criteria: performance, parser independence, and standards compliance.

Performance
Each XML binding solution has its own internal mechanism of dealing with XML be it DOM, SAX, StAX or proprietary. Unless you require access to the DOM (such as for info set preservation) be wary of DOM-based solutions, as they are more memory intensive as both the DOM and your object model are in memory.

Parser Independence
Consider the environment that the binding solution must run in. A common environment is an application server; each comes with an XML parser. If the XML binding solution you've chosen is dependent on a different parser it may not be usable with that application server.

Standards Compliance
JAXB has been introduced as the XML Binding standard. In JAXB 2.0 objects are implementation independent, allowing you to easily switch between implementations and avoiding vendor lock-in.

TopLink OXM:
http://www.oracle.com/technology/products/ias/toplink/preview/10.1.3dp4/objectxml/index.html

-Blaise Doughan
 Team Lead, TopLink OXM

I never understood what XML beans brought to the table except another code generation framework.

Heh ;-) .. not _those_ XML beans, but our XmlBean framework. (BEA used the same name as we had, then donated their project to Apache.) Our XmlBean framework is very simple, and provides a base class and a set of property adapters that allow you to create Javabeans that come with a whole bunch of handy functionality (e.g. both XML and optimized binary serialization).

Also, why would you hold on to your own DOM API when JDOM appears to be much more successful (other than wasting resources converting)?

Our API is widely and successfully used .. by us ;-) .. and it was in place before the various usable Java DOM APIs were available. There's no reason for us to convert from using an efficient, stable and tested API to what is an unknown (to us). Also, it would introduce an external dependency, which (so far) we've avoided.

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

I've never understood why anyone would prefer JDOM to dom4j. I've used both and have found that dom4j is far mor flexible and powerful. Its more rapid progression versus JDOM - dom4j is an offshoot of, are evidence of its superior architecture. JDOM uses an unsophisticated concrete class approach which too often forces you to rely on inheritance in order to extend functionality. With dom4j's use of factories and interfaces, I can easily and safely extend and optimize when and where I need to and maintain forward compatibility.

The problem I have with most of the dom (jdom, dom4j, DOM) and XML bean approaches is that many of them end up having to support a range of XML features which are excess baggage to those of us who are dealing strictly in messages and data and not publishing or documents. I don't need CDATA, PCDATA, or DTDs, but I do need elements (without mixed content), attributes, data types and structures (XML Schema is adequate), Namespaces and XPath. XSLT and XQuery or O.K. but not essential.

I wish XML would spawn two official subsets - one for data and one for documents and define a common ground for moving data between the two. Then our friends at JDOM, dom4j, XMLBeans, etc. could focus on just the data subset of XML standards.

And of course, but I always preferred our own DOM API (com.tangosol.run.xml) and XmlBean binding framework ;-)

I do not know why there is so such an animosity to home grown frameworks and libraries in the TSS community (not in this thread but in others). Sometimes they give more value then public (OSS or commercial), sometimes don't.

We also have even two home grown XML libraries:

- DOM decorator that is, for example, specificaly aimed for easy extracting configuration parameters from XML configuration files,
- And full JDK 1.1 compatible XML parser (no available had meet our needs, Aelfred had some show-stopping bugs for us, etc...).

IMHO, there are situations where rolling-your-own-stuff is a viable option, even more than it is currently anticipated by the community.

Off topic: still no post preview nor post editing on TSS :(.

MindElectric (I do not know who owns this company now) had very fast but proprietary XML parser used in their (also very fast) web services stack called Glue (anybody knows what happened with it?).

MindElectric (I do not know who owns this company now) had very fast but proprietary XML parser used in their (also very fast) web services stack called Glue (anybody knows what happened with it?).

According to this article:
http://www.adtmag.com/article.asp?id=8367

Glue seemed to be very advanced for its time.

...in 2003.

Wish there was more depth to the article. I have started getting a creepy feeling that most of the articles on techtarget lack sufficient information. Probably it is just meant for a different audience..

anand raman

Wish there was more depth to the article. I have started getting a creepy feeling that most of the articles on techtarget lack sufficient information. Probably it is just meant for a different audience.. anand raman

I think the purpose of these tips is to make people aware of the possibilities and mention things you may never hear of otherwise. The response of readers with new leads has already expanded my horizons.

My tip is, if you can possibly use Java 5 then use JAXB 2.0, it rocks!

https://jaxb.dev.java.net/

Particularly if you have XSDs or WSDLs to work with, rather than arbitrary XML.

If you have POJOs and just wanna marshall them to and from XML then XStream rocks

http://xstream.codehaus.org/

Or if you are mostly reading general blobs of XML then XPath rocks. Maybe try Jaxen

http://jaxen.org/

Or the JAXP 1.3 stuff for XPath


James
LogicBlaze

Did not read the article (requires registration). Anyway, a word of caution for prospective users of StAX. Older BEA implementation did not work for me because it did not support external entitiles. Oracle implementation failed with internal error, whatever. StAX parser from JWSDP 1.5 (apparently, provided by BEA as well, but this is a newer version) works fine but has a serious parsing bug. Parser/writer from JWSDP 1.6 works fine so far.

Nux (http://dsd.lbl.gov) integrates best-of-breed components, containing extensions of the XOM, Saxon and Lucene open-source libraries.

It is a robust and natural commodity Java tool set for XML, XQuery, XPath, schema validation, fuzzy fulltext similarity search, binary XML and related technologies. It avoids XML nightmares, enabling you to mix and match powerful main-memory XML tools that fit your needs, in natural, straightforward, seamless, effective and standards compliant manners.

Nux (http://dsd.lbl.gov) integrates best-of-breed components, containing extensions of the XOM, Saxon and Lucene open-source libraries.It is a robust and natural commodity Java tool set for XML, XQuery, XPath, schema validation, fuzzy fulltext similarity search, binary XML and related technologies. It avoids XML nightmares, enabling you to mix and match powerful main-memory XML tools that fit your needs, in natural, straightforward, seamless, effective and standards compliant manners.

The location of Nux was not obvious from that page but I found it at http://dsd.lbl.gov/nux/
It looks like NUX deserves a Tip for integrating so many tools - I would like to hear from anybody actually using it.
Bill

I think the XMLBean is better than the others xml tools. You can access the xml like an object. Also, it can validate the xml with schema.