Sign up ×

I'm sure this might have been discussed at length or answered before, however I need a bit more information on the best approach for my situation...

We have some large XML data (anywhere from 100k to 5MB) which we need to inflate into Java objects. The issue is that the data doesn't really doesn't map onto an object very well at all, so we need to only pull certain parts of the data out and create the objects. Given that, solutions such as JAXB or XStream really aren't appropriate.

So, we need to pull XML data out and get it into java objects as efficiently as possible.

Possible Solutions:
The way I see it, we have 3 possible solutions:

  • SAX parsing
  • DOM parsing
  • XSLT

We can load the XML into any JAXP implementation and pull the data out using one of the above methods.

I have a few questions/concerns:

  • How does XSLT work under the hood? Is it just a DOM parser? I ask because XSLT seems like a good way to go, but I don't really want to consider it if it won't give us better performance than DOM.
  • What are some popular libraries that provide DOM, XSLT, and SAX XML parsers?
  • In your experience, what are the reasons for picking DOM, SAX, or XSLT? Does the ease of use of DOM or XSLT totally dominate the performance improvements SAX offers?
  • Any benchmarks out there? The ones I've found are old (as in, 8 years old). So some recent benchmarks would be appreciated.
  • Are there any other solutions besides those outlined above that I could be missing?

A few clarifications... You can use XSLT to directly inject values into a Java object... it is normally used to transform XML into some other XML, however I'm talking from the standpoint of calling a method from XSLT into java to inject the value.

I'm still not clear on how an XSLT processor works exactly... How is it feeding the XML into the XSLT code you write?

share|improve this question
is xpath an option? –  Brad Cupit Nov 10 '10 at 22:35
See my answer below. The XPath to parse out a few fields is normally very simple indeed and often very quick. –  Fortyrunner Nov 10 '10 at 22:46
XSLT use XML trees, so it use some DOM provider. But here you have to measure the performance (and developing time) between your "plain" DOM implemantation and the focus language for transformations... XSLT also can works with SAX and streaming (check Saxon XSLT processor). I think you can begin the chain with this and then use some bridge so streamed result will feed some SAX directly in order to work with a well known library for XML-Java object. –  user357812 Nov 10 '10 at 22:48
I think you should investigate schemaless data bindin technique outlined in this article, it seems ideally suited for your situation.… –  vtd-xml-author Jan 3 '11 at 20:26
@vtd-xml-author - JAXB is a schemaless data binding technique. Just because you can generate an object model from a schema with JAXB, doesn't mean you have too. The article you posted also incorrectly portrays Castor as requiring a schema. –  Blaise Doughan Jan 4 '11 at 18:32

5 Answers 5

up vote 3 down vote accepted

Use XSLT to transform the large XML files into a local domain model that is mapped to java objets with JAXB.

Start with the JDK 5+ built in XML libraries (unless you absolutely need XSLT 2.0, in which case use Saxon)

Don't focus on relative performance of SAX/DOM, focus on learning how to write XPath expressions and use XSLT, and then worry about performance later if and only if you find it to be a problem.

The Eclipse XML editors are decent, but if you can afford it, spring for Oxygen XML, which will let you do XPath evaluation in realtime.

share|improve this answer
Why, though, couldn't I just map the XML to my domain model when processing the XML with XSLT? I don't understand the benefit of using XSLT to make it into a format which could be used by JAXB, only to have JAXB parse the XML again. –  Polaris878 Nov 11 '10 at 15:12
IME, there really isn't much performance comparison between SAX and DOM, it really just boils down to "are your documents small enough to parse in-memory?" If so, then a DOM-based parser is the way to go. If not, then you need to go to SAX. If your needs are really simple, don't be afraid to skip the whole API and just treat your document as a stream of text and parse it yourself. I often do this for message routers, where the few fields I need to parse are at the start of the document. –  TMN Nov 11 '10 at 16:00

We had a similar situation and I just threw together some XPath code that parsed the stuff I needed.

It was amazingly quick even on 100k+ XML files. We went as low tech as possible. We handle around 1000 files a day of that size and parsing time is very low. We have no memory issues, leaks etc.

We wrote a quick prototype in Groovy (if my memory is accurate) - proof of concept took me about 10 minutes

share|improve this answer

JAXB, the Java API for XML Binding might be what you want. You use it to inflate an XML document into a Java object graph made up of "Java content objects". These content objects are instances of classes generated by JAXB to match the XML document's schema

But if you already have a set of Java classes, or don't yet have a schema for the document, JAXB probably isn't the best way to go. I'd suggest doing a SAX parse and then building up your Java objects during the parse. Alternatively you could try a DOM parse and then walk the resulting Document tree to pull out the parts of interest (maybe with XPath) -- but 5MB of XML might turn into 50MB of DOM tree objects in Java.

share|improve this answer
This is why I'm asking about XSLT though... I need to know how an XSLT processor works... whether the most common implementations are DOM or SAX. XSLT is easier to work with than SAX, but if it is too much of a performance hog then we'd have to go with SAX. –  Polaris878 Nov 11 '10 at 3:55
JAXB can start from Java classes. Check out how the @XmlPath extension in EclipseLink JAXB (MOXy) can be used to leverage XPath for this use case:… –  Blaise Doughan Nov 11 '10 at 21:25
@Blaise: Cool, thanks! –  Jim Ferrans Nov 13 '10 at 16:07

DOM, SAX and XSLT are different animals.

DOM parsing loads the entire document into memory, which for 100K to 5MB (very small by today's standards) would work.

SAX is a stream parser which reads the XML and delivers events to your code for each tag.

XSLT is a system for transforming one XML tree into another. Even if you wrote a transform that converts the input to a more suitable format, you'd still have to write something using DOM or SAX to convert it into Java objects.

share|improve this answer

You can use the @XmlPath extension in EclipseLink JAXB (MOXy) to easily handle this use case. For a detailed example see:

Sample Code:

package blog.geocode;

import javax.xml.bind.annotation.XmlRootElement;
import javax.xml.bind.annotation.XmlType;

import org.eclipse.persistence.oxm.annotations.XmlPath;

@XmlType(propOrder={"country", "state", "city", "street", "postalCode"})
public class Address {

    private String street;

    private String city;

    private String state;

    private String country;

    private String postalCode;

share|improve this answer

Your Answer


