xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brett McLaughlin" <br...@newInstance.com>
Subject Re: JDOM in Apache (was Re: xml.apache.org charter proposal)
Date Sun, 01 Apr 2001 19:29:35 GMT
Arnaud has some points that are good, and some that I want to address. See
comments inline... and we'll try and be nice to each other this go round ;-)

----- Original Message -----
From: "Arnaud Le Hors" <lehors@apache.org>
To: <general@xml.apache.org>
Sent: Sunday, April 01, 2001 12:52 PM
Subject: Re: JDOM in Apache (was Re: xml.apache.org charter proposal)


> I'm being cited so I should probably state my position to make it clear.
>
> It is true that I think we should not use JDOM in Xerces because it is
> not a standard. But it is also true that I think we should not use JDOM
> in Xerces because I don't like it. So both Ted and Scott are right. :-)

Good starting point :) It's also fair to point out that I don't like DOM,
which is why Arnaud and I are often at odds ;-)

>
> Now, before Jason or Brett jumps in with one of their favorite
> statements a la 'but JDOM is now a JSR and is in the process of becoming
> a standard', let me explain why I don't like it. Because this won't be
> changed by the fact that JDOM becomes a standard.

OK. So that's fair; if the standard argument goes away, though, we can at
least talk technical merits; that's a more interesting discussion, anyway.
However, I would think that it would be apparant that JDOM standardization
at least /increases/ the impetus to have a JDOM option as part of Xerces,
even if it's an add-on (as we've always said would be a good compromise).

At the end of the day, if Xerces (as a parser) is only what you or another
developer likes, I think that is a problem. If this was Cocoon or some other
one-off type new innovation, that wouldn't be true. But this is an "XML
parser" and as such needs to support XML parser and related APIs in my
opinion. But I still think it's good to discuss JDOM technically, as (1) it
educates and (2) it can improve JDOM.

>
> I don't like JDOM mostly because it has been promoted from the beginning
> on bogus assertions, by people who don't know what they were talking
> about (Jason admitted to me, in public, that he had never read the DOM
> spec). To start with, even though it doesn't compare to the DOM, it's

OK. Let's deal with that, first. That's probably true. However, Jason never
was and never will be the XML guy; he's the Java guy. And he'll also admit
that I wrote 90% of the code for the first three or four versions of JDOM,
including all the DOM and SAX code. He's now very current on those specs and
does lots of work on the two, but you are saying "JDOM authors don't know
XML because Jason doesn't know DOM." Really a false assertion. I at least
know XML well enough to write the O'Reilly book on Java and XML (regardless
of what you think about that), so that's certainly something. The fact that
I've written a Java API for XML, a data binding API for XML (twice now), and
close to thirty articles for online publications (including IBM, over 5 for
them!) should establish me as knowledgeable about XML. So to say I don't
know what I'm talking about is simply false ;-)

> been promoted as 'faster and smaller than DOM'. But how in the world can
> a set of concrete classes be faster and smaller than a set of
> interfaces?? This doesn't make ANY sense.

Hmmm... smaller? Maybe "smaller memory footprint" which turns out to be true
in the sense which we used it; which is, for an XML document (call it "A"),
using any existing DOM implementation within a parser we have found (Oracle,
Xerces, XML4J, Crimson, etc), using JDOM to parse that document via
SAXBuilder versus using DOM, the JDOM parse/build is faster than the DOM
one. That's emprical evidence. That's also still the case when using Xerces'
deferred DOM, btw (although I don't have the numbers to post, that's a
recent test). And that's for any XML document we've tried, not ones we have
specifically formulated.

Yes, there is the possibility that a better DOM impl could be written, and
that it might be faster than JDOM. But to say that "JDOM might not be faster
than some theoretical DOM" is, at best, fairly stupid to say ;-) Just
because we're technical doesn't mean we have to be idiots about promoting
JDOM, right? :-) And there is certainly no value in comparing "size" of
classes, unless you mean memory footprint. And btw, the deferred DOM did
have a smaller memory footprint, but as we all know that is a tradeoff for
performance. But, I want to be in full disclosure mode here :) So I don't
see those statements as ambiguous; we don't hide that JDOM is concrete
classes. In fact, it's one of the first things we point out, as that has
been a popular aspect of it. At the same time, I'm not going to lecture for
30 minutes on classes versus interfaces to ensure that people walk away with
a byte-level understanding of what a faster implementation means.

>
> In addition, I really dislike the way Jason and Brett have been
> marketing JDOM. They say it has nothing to do with DOM, but its name for
> a starter leads the mass to confuse the two. And this is no accident.

It has plenty to do with DOM. It's a tree model for parsing XML documents,
it's a document object model, etc., etc. I've never said that; I've said it
is not related to the DOM specification in implementation. We don't wrap
interfaces, extends interfaces, extend impl classes, or anything technical
that ties or relates us to DOM. In fact, I finished the 2nd edition of my
chapter on JDOM just this week, and all this is very clear in that.

> Even though they don't compare, DOM is being used to leverage JDOM. At
> the XMLDevCon in San Jose, after a two hour presentation on JDOM a guy
> asked 'DOM Level 2 just became a recommendation, is JDOM compliant?'.
> Jason clearly annoyed first tried to explain why it is not, but this
> statement was quickly softened by Brett who said it was 'DOM Level 2
> compatible' because one could build a JDOM tree with DOM Level 2. At
> that point the guy looked relieved... What do you think he understood???

Oh, come on ;-) Do you, every time someone asks you how fast Xerces builds a
DOM tree, explain that it is actually SAX being used to build the DOM tree,
and their question is really not correct? No; you answer them. And that's
exactly what I would do. I a conference setting, you answer at the level of
the questioner. Jason gave some technical answers, the guy looked confused,
so I brought it up to his level. That's a good presentation (by both of us),
not marketing ;-) I understand that you like DOM far better, and I'm OK with
that; but I'm not going to give you a hard time about not mentioning why,
for example, using the DOMParser in Xerces might throw a SAXException... is
that something you always cover? Isn't that confusing to some who you are
trying to get a higher-level point across to?

>
> I also dislike the fact that from day one JDOM was self declared as an
> 'emerging standard'. De facto standards happen because of their
> technical merit. There is no need to give a presentation in every
> conference and write an article in every magazine for that to happen.

Fair enough. And I think it's also fair to say that we have significantly
toned down the "marketing machine." I haven't written a JDOM article in 9
months, Jason in about that long. The last presentation on it was at the ORA
conference (duh... that's where it got started), and before that at XML
DevCon. So 3 or 4 presentations a year is not that much; however, it's fair
to say that we get asked to do these, and now have many others in the
community doing the work for us. The latest version of Java Examples in a
Nutshell covered JDOM, Elliotte Rusty Harolde includes it in his XML
presentations and has done JDOM presentations, Simon St. Laurent uses it in
some of his... there is certainly an emerging API, and I'll leave Sun to
standardize, as they have wanted to do (without our urging I might add).

So I will apologize for the initial way in which things were handled; I
admit that I, and we, could have been more tactful. We were excited, and
excited, and ... well, excited. I think that's OK in general, and for the
trouble we caused I think we both regret that. However, that's in the past,
and I think it's more than fair to say that we've been increasingly tactful
and careful. When is the last time you have seen Jason or I on lists like
this talking JDOM? In fact, it was Ted that brought it up this time (thanks,
Ted ;-) ).

>
> And apart from all of this, I don't like JDOM because it is too much
> object oriented. In my opinion relying on Java 2 collections which force
> you to create new objects to perform a simple traverse is bad. Yes, I
> know, I'm going to choke more than one person here, but the fact is that
> objects are expensive, despite what Sun's marketing machinery would like
> us to believe. As a matter of fact I wish the DOM wasn't so much OO. And
> for that reason I certainly don't think DOM is the only API that should
> exist to manipulate XML documents in memory. I would fully support a DTM
> effort at Apache (cf Scott's message).

OK. I agree, technically, with you here 100%. Objects are VERY expensive,
and trusting a JVM to take care of that is not very smart, IMO. However,
that does not mean, in any case, that objects are not very USEFUL. 90% of
Java developers never want to worry about performance optimizations by using
weak references and the like, and the other 10% go out and buy JProbe.
Optimization these days is using StringBuffers instead of Strings. So, we
had a choice; we could either put in all these optimizations, and create
classes for our own lists and things, and confuse some users (as, honestly,
DOM does). Or, we could accept that people want to work in a way that's
familiar to them, and accept that that way has a cost (we all know C is
still faster than Java for most tasks when programmed in correctly, but
which language are we all using?). Once you accept that, as we did, it
became clear that people wanted to work in that way; that way, in this case,
included Collections and OO-programming. So we made JDOM conform. So yes, it
could be faster, it could be optimized, it could be less costly to use; but
at the COST of usability. And for JDOM, the goal is USUABILITY. So I agree
with you technically here completely, but I also think that JDOM clearly
states that its goal is usability, not to squeeze out every drop of
performance at the cost of that usability. I think we've been very clear on
that (check the webpage - it's in the mission statement), so using that as a
watermark is not really appropriate, IMO.

Again, lots of good points, Arnaud. Some I agree with, some I think are
valid but I don't agree with, and there are a few that are based on some
incorrect information, which I've tried to correct to some degree here. I
hope we can both agree to disagree a little more nicely here, and accept
that at times I am going to cast a poor light on DOM, because I don't like
it; and the converse is true for you, which is fine too. I'd just rather
keep the war off of the streets... fair enough?

-Brett

> --
> Arnaud  Le Hors
>
> ---------------------------------------------------------------------
> In case of troubles, e-mail:     webmaster@xml.apache.org
> To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
> For additional commands, e-mail: general-help@xml.apache.org
>


---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org


Mime
View raw message