SV: [jdom-interest] jdom and dom4j

[Christian Holmqvist, IT, Posten]

Hi!

> The comparison doesn't address the most interesting concerns people
> have.  One important thing not mentioned is how complicated the APIs
> are.  JDOM's founding goal has been simplicity with an easy learning
> curve with power tools available when necessary.  In that way 
> it's like Java itself.  

JDom is might be easy to learn and use for a novice, anyone that want's to
use XML proffesional and have maybe a little bit more the the most trivial
knowledge about how XML works won't agree with that JDOM is "curved with
power tools". Or it might be that it is since all power tool is made up with
small rather basic parts but a proffesional developer don't want to put
these small features togheter every time just because there is a reluctance
to put them in the API.

Dom4j might be a bit harder to learn, and is not always as simple that a
novice would want but on the other hand a proffesional developer only have
to implement about 1/3 of the amount of code that the same implementation
with JDom requiers (I have resently thrown JDom out and implemented the same
functionality with Dom4J so the are not speculation!) and since time is
money it is to expensive to work with JDom.

> 
> The fact JDOM is going through the JCP process as an official 
> JSR isn't mentioned either.

Who cares? This only means that JDom is protected by SUN and got SUNs
permission to mess up!

> Looking just at the facts on the page, JDOM now has 
> integrated XPath (as of the latest CVS code) and we've had integrated
JAXP/TRaX support for
> quite a long time.  Both of those bullet items should be updated.  

Have you read the page at all the first paragraph:
"This page attempts to survey the landscape of available XML object models
and compare and contrast their features. The information in this table is
correct to the best of our knowledge and we will try and keep this
information as up to date as possible. If you think there's anything wrong,
please let us know here. "

I'm sure that the information will be changed if you point out what to
change.

> The "Massive documents" and "event-based processing" items probably
> refer to dom4j's feature to only build parts of the tree.  

The performance test is not performed by Dom4j but rather ibm. The linke is:
http://www-106.ibm.com/developerworks/xml/library/x-injava/index.html
So that any as you put it "dom4j's feature" is very doubtfull.

> Laurent wrote similar code for JDOM.  Look at the "spanner" code in 
> jdom-contrib.  If it becomes popular and people like the API, we'll make
it core.

Why don't you put some of these features in the API instead, installation,
maintance and development is both harder and demands more time if both
contributions and the "official" release has to be followed.
To only listen to the majority has lead to that JDom is a rather empty API
with little or no nice time saving features that is needed in any
proffesional development environment.

> Hmm, dom4j says "built on Java interfaces".  What that probably should
> say is it's built on its own interfaces.  Both dom4j and JDOM support
> standard interfaces like java.util.List, Cloneable, and so on.

What they probably mean is that Dom4j is based on a interface structure that
lets the developer add new items to the XML standard if wanted.
This is ofcourse a discussion and a request that has been discussed on this
mailinglist a lot and you constantly have refuesed to address because it
would complicate the JDom API. 
 
> As for the Schema item, you can use Schema in JDOM if the parser
> supports schema.  The bullet item may mean something else 
> though.  Hard to tell.

Again, the Dom4j ppl would probably be glad to explain to you what it
means...
 
/Cheers Christian