[jdom-interest] RE: dom4j similar to JDOM ?

[James Strachan]

Hi Jason

From: "Jason Hunter" <jhunter at acm.org>
> Tobias Rademacher wrote:
> >
> > Have a look at
> >
> > http://www.dom4j.org/compare.html
>
> Not mentioned in the comparison:
>
> * JDOM is a JSR with the official support of the JCP

Sure, JDOM may well become a JSR standard one day. DOM is already a W3C
standard right now.  The page in question is meant to be a feature
comparison for developers.


> * JDOM has an active user community
>   (compare http://lists.denveronline.net/lists/jdom-interest/
>    to http://www.geocrawler.com/archives/3/8798/2001/)
> * JDOM has had tens of thousands of downloads over the past year
> * JDOM has been written about in several books and many articles

Sure. JDOM has been around for about 2 years whereas the 0.1 release of
dom4j was made the end of January this year. So JDOM has been around much
longer.

Plus you and Brett have evangelised JDOM at many user groups, trade shows
and conferences together with writing books and articles on it. To date,
dom4j has just appeared as announcements on a couple of mail lists thats
all - so its pretty new stuff by comparison. So its hardly suprising that
JDOM has a larger community behind it at the present time. This will
hopefully change over time.

To date only about a thousand downloads of the release builds have been made
of dom4j (I've no idea how many daily snapshots are downloaded) though as
dom4j approaches 1.0 with XML Schema Data Types support, I expect that
number to rise some.

Right now today SAX and DOM probably have the biggest user community of any
XML technology. There's no direct correlation to user community size and the
power, flexibility, performance and ease of use of software.


> Some of the items listed in the dom4j comparison also have a touch of
> "spin" to them where perhaps the full story should be told.

I'm trying to keep the comparison page to be a factual feature wise
comparison. If there's any innaccuracies, I'll happily change them. I'm
trying not to "spin" anything.

If you wish to talk about "spin" then surely JDOM's "lightweight" claim is a
much better example. As Dennis' results show, JDOM is the slowest XML
technology around for parsing and navigating XML documents. The DOM
implementations are still the leaders in terms of being lightweight and
fast.


> Here's a
> little bit of background.
>
> For the "Integrated XPath support" item:  dom4j claims to have this
> while it claims JDOM does not.

JDOM has no XPath API whatsoever yet AFAIK. dom4j has been designed from the
ground up to have an integrated XPath API.
API and implementation are quite different things.


> The reality of the situation is that
> dom4j ported the code.werken.com library (written for JDOM) and
> integrated it into the dom4j library.

Sure, the origins of the current XPath implementation are those from the
code.werken.com library, though much development work has been done on it
since then. Though I say again, API and implementation are different things.
dom4j can plug in any XPath engine for its implementation.

For example, the native DOM implementation of dom4j will probably use Xalan
as its XPath engine. One day maybe JAXP will include XPath support which
dom4j could then use...

<aside>
One day, I'd like to get an open source, object model agnostic XPath
implementation together, maybe using Apache's or Saxon's codebase as a start
then integrate the best bits from the dom4j/werken engine and refactor the
code so that we can all share the same XPath engine across all XML object
models: DOM, dom4j, EXML, JDOM and maybe even SAX.

As an aside it would be nice to be able to do XPath queries over normal
JavaBeans too - there's been discussions on Jakarta-Commons project on this
very topic if anyone's interested. Already Dmitri Plotnikov has done some
impressive work in this area.
</aside>


> For the "Support for JAXP/TRaX for XSLT integration" item.  I'm not sure
> why the chart says No with JDOM considering JDOMSource and JDOMResult
> are in jdom-contrib.

OK, how about I say "optional" in the chart as its an optional add on in the
seperate jdom-contrib package and not part of the JDOM API? I'm open to
suggestions on how to make the chart more accurate.


> The reason those classes are not into the core yet
> is we're working with Sun to decide if JDOMSource and JDOMResult are
> better provided by JDOM or by JAXP itself (since SAXSource/SAXResult are
> provided by JAXP and not by SAX).  I suspect with the next JAXP still a
> way off, we should just incorporate them into JDOM directly.

Agreed. Forcing users to be dependent on a version of JAXP is a bad thing
IMHO.

e.g. many J2EE servers have trouble supporting JAXP1.1 today as they ship
integrated with JAXP1.0. (e.g. BEA 6.0 SP1).


> For the "Capable of processing massive documents" item.  I see the
> benchmarks Dennis published recently show dom4j using more memory than
> JDOM.  Now, neither JDOM nor dom4j have been tuned at all yet, but I'd
> be curious what dom4j code backs up that claim.

There's an entry in the FAQ that describes how to process massive XML
documents if you're interested.

http://dom4j.org/faq.html

The basic idea is that dom4j has an integrated event based notification
mechanism that allows massive documents to be processed in an event based
manner, rather than loading it all into memory in one go.

It allows path based notification so that, for example, large database
generated XML documents to be processed easily and efficiently in a 'row by
row' like fashion

It means developers don't have to 'get their hands dirty' going down to the
SAX level writing XMLFilters and such like - they can just implement a
simple ElementHandler and away they go.

Work is currently under way to make this notification mechanism easier to
use and more powerful, so this may well change a little in the next 0.4
release.


> I'm not sure what the "Continuous XML Streams" bullet is about.
> Considering JDOM has pluggable builders such that you can build from
> even a database result set, I'm sure it wouldn't be hard to build from
> any sort of stream.

The "continous XML Streams" refers to users who wish to process (say)
continuous XML log files where processing is required before the log file is
finished. Its another use case for the event based mechanism.

Sure in JDOM you can always write another builder. In dom4j the approach is
taken that we try to avoid a user ever having to write their own builders -
a builder is usually a complex piece of code to get right and its alot of
work to maintain and to make it perform.

One thing I've found from the users in the dom4j community is developers are
happy (and sometimes actually want to) derive and implement their own
Document, Element or Attribute implementations as they are usually quite
simple classes to understand and extend. What they don't want to do is write
their own (SAX or DOM) builders which are often quite complex.

Anyways, thanks for your comments Jason. I'll try update the comparison page
to fix the inaccuracies you've brought up. If there's any more you're aware
of just let me know.

James


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com