You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@xml.apache.org by Arnaud Le Hors <le...@apache.org> on 2001/04/01 19:52:29 UTC
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. :-)
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.
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
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.
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.
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???
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.
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).
--
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
Re: JDOM in Apache (was Re: xml.apache.org charter proposal)
Posted by Jason Hunter <jh...@collab.net>.
Arnaud Le Hors wrote:
>
> Brett McLaughlin wrote:
>
> > ... you are saying "JDOM authors don't know
> > XML because Jason doesn't know DOM."
> > Really a false assertion.
>
> You're wrongly extrapolating what I say here. All I say is that Jason
> criticized the DOM even though he didn't know it. Nothing else.
I criticized DOM because I had used it on a project, and found it to be
highly counterintuitive. You don't need to read a spec to find
something counterintuitive; you just need to try to use it and find
yourself muttering swear words. :-)
While Brett and I were creating JDOM I explicitly held-off reading the
DOM spec because I wanted to be able to brainstorm Java-style approaches
to problems without a DOM bias. Brett acted as the XML guy experienced
with DOM who could check if my Java-perspective ideas satisfied XML's
full needs. We made a good team that way.
-jh-
---------------------------------------------------------------------
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
Re: JDOM in Apache (was Re: xml.apache.org charter proposal)
Posted by Arnaud Le Hors <le...@us.ibm.com>.
I've been pondering whether I should reply or not. I don't want a war,
I'm a peaceful guy. So I was thinking that maybe simply dropping the
ball was the best thing to do. As a middle ground kind of solution I
have decided to simply clarify a few points and to leave aside the rest
that might be more controversial.
Brett McLaughlin wrote:
> ... you are saying "JDOM authors don't know
> XML because Jason doesn't know DOM."
> Really a false assertion.
You're wrongly extrapolating what I say here. All I say is that Jason
criticized the DOM even though he didn't know it. Nothing else.
> And there is certainly no value in comparing "size" of
> classes, unless you mean memory footprint.
There can actually be value in comparing the size of classes in contexts
such as hand-held devices, but I meant memory footprint.
Note that the DOM implementations you're referring to are all 'vanilla
implementations'. These are implementations which do not carry any
particular behavior and which are not designed for any particular use.
Too few people know that this is not what the DOM was designed for in
the first place though. The DOM was designed so that applications that
have their own data structures could expose them in a standard way.
Which is why it's only made of interfaces.
Performance and memory footprint may greatly vary depending on the
implementation, but that's the price to pay for interoperability. It's
better to run slow than to not run.
JDOM is radically different for that matter. It's a specific structure.
If it suits your needs that's fine but if you have your own data
structure you have to convert from one to the other. Note that this is
often what people do with vanilla DOM implementations and I'm the first
one to say it's wrong! The right model is: build your own data structure
with SAX and expose it through DOM if you need to.
> 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?
FYI, the DOMParser in Xerces does not really use SAX. It's based on a
native SAX-like API.
> I understand that you like DOM far better,
I challenge you to find any quote from me stating that I like DOM. As
I've stated in the past I like STANDARDS. Being standard is to me far
more important than being something I like from an academic point of
view.
> 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?
It certainly is, but that's only because there is currently no standard
API to parse a document in DOM. When DOM Level 3 comes out with its
'Load and Save' module we will implement it and all this should
disappear.
--
Arnaud Le Hors - IBM Cupertino, XML Strategy Group
---------------------------------------------------------------------
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
Re: JDOM in Apache (was Re: xml.apache.org charter proposal)
Posted by Ted Leung <tw...@sauria.com>.
For the record, it was not my intention to re-ignite the DOM vs. JDOM war.
I could have used W3C Schema vs. TREX or RELAX as well. The original
context was the use of "standards" as a constraint on the kinds of projects
covered by the charter. During the discussion, it was claimed that
"standards"
had never been used to exclude promising work from xml.apache.org. I
dredged up the JDOM issue because in fact "standards" had been used
for this purpose.
My position is essentially the one the Scott has stated recently. Standards
(good or bad) are an important part of what we do here. I don't really
think
that's ever been open to debate (at least in my mind). But standards are
not the only thing that is important for xml.apache.org projects.
We now return you to our regularly scheduled disagreement...
----- Original Message -----
From: "Brett McLaughlin" <br...@newInstance.com>
To: <ge...@xml.apache.org>
Cc: "Jason Hunter" <ja...@jdom.org>
Sent: Sunday, April 01, 2001 12:29 PM
Subject: Re: JDOM in Apache (was Re: xml.apache.org charter proposal)
> 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" <le...@apache.org>
> To: <ge...@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
>
---------------------------------------------------------------------
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
Re: JDOM in Apache (was Re: xml.apache.org charter proposal)
Posted by Brett McLaughlin <br...@newInstance.com>.
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" <le...@apache.org>
To: <ge...@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