cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett McLaughlin <>
Subject Re: JDOM and Thank You :)
Date Thu, 27 Apr 2000 19:28:05 GMT

Scott Boag/CAM/Lotus wrote:
> "Brett D. McLaughlin" <> wrote:
> > However, in response to your main point, JDOM will maintain complete
> > interoperability with DOM and SAX for as long as those APIs are heavily
> > used.
> The problem I see with the DOM adapters is that they look to be cloners,
> not adapters.  Am I missing something?  If I use a DOM adapter, I end up
> getting two trees in memory, and thus negate any benifit to using JDOM, and
> probably add to the expense of using DOM.  If I edit the DOM tree, the JDOM
> does not get updated.

No - The DOMAdapter wraps a parser behavior to provide a standard
mechanism to obtain a DOM Document.  There is not any tie between a
DOMAdapter implementation and JDOM - they are purely utility classes
(providing behavior that, frankly, is better than JAXP, in our opinion -
works with DOM Level 1 and 2, and any parser, including future ones).

So once the DOM Document is obtained, that can be converted into a JDOM
Document object.

// No validation, user default parser (Xerces)
Builder builder = new DOMBuilder();

// Get the JDOM Document
org.jdom.Document doc =;

The DOMBuilder /uses/ a DOM Adapter class to get the DOM Document
object, converts it to JDOM, and throws away the DOM Document object.

There is /not/ an underlying DOM tree, we think that's a total waste of
time.  In fact, there's no good reason to ever use DOM Builder like
this, use SAXBuilder, which is always faster.  However, this is useful:

DOMBuilder builder = new DOMBuilder();
org.jdom.Document doc =;

This sounds like the case you are talking about - if you already have a
DOM tree, you won't even use the DOMAdapter classes.  They are only when
you need a DOM tree from a stream, url, etc of XML data.

if you have an existing (pre-built) DOM tree, you can pass it into the
DOMBuilder build method and get out of it a JDOM Document object.  Then
do your mods to JDOM (which is lighter in memory, totally usable and
intuitive), and then use DOMOutputter or SAXOutputter or whatever else
to output it to the next component in your chain.  In the meantime, no,
it doesn't modify the DOM tree you supplied as input - we don't want
to.  Just throw that thing out the window, or null it, or whatever you
want.  We are convinced that we are so much faster and easier to use
than DOM in these typical situations that building, using, and
outputting JDOM will still beat out just plain using a DOM tree.

Hopefully that makes some sense to you - we are interoperable, not on
top of, DOM.


> (sorry, we should probably move this to the JDOM list...)
> -scott

View raw message