[jdom-interest] Announce: JDOMPlus a flexible XML framework for Java

[Jason Hunter]

> > It's possible to implement Element and Attribute each with just 1
> > required instance variable.
> 
> Not in JDOM today. 

If JDOM were called final, then that would matter.  As is, we've been
trying to solidify the API, then we'll get to work on minimizing memory
consumption.

> > Basically use association for other data as
> > needed so memory is allocated to hold an attribute list only if one
> > exists, for a namespace map only if one exists, and so on.
> 
> Ah you're saying it doesn't really matter that much if the 7 instance
> variables don't ever point to something?

No, I'm saying there are ways to implement Element without 7 instance
variables.

> I'm afraid I don't agree here at all. Its a waste of memory and
> computation to force base classes to inherit unnecessary instance
> variables. 

It's a waste of human computation to complicate the API unnecessarily. 
Humans are far more expensive than computers.

> > I too don't
> > like 7 instance variables, but I expect we can cut it down.
> 
> How?
> 
> Lets say that for a given DTD I know that an Element is empty and 
> has no attributes but just a text value. 
> (This is actually suprisingly common in
> XML - that an element only contains text).
> 
> It would be nice if it were technically possible to use a nice 
> small element implementation which just used one internal instance
> variable, a String.

Two problems with that idea.  One, it'll be a real pain in the ass to
implement.  Two, in production use for two programs communicating,
people often opt not to use validation and then these optimizations
wouldn't be available.

> JDOM currently disallows this as the lowest common demoninator is the
> default Element implementation which comes hardwired with 7 instance
> variables. 
> Whether they refer to objects or not they are a waste of RAM.
> This seems like a good argument to me for interfaces or abstract base
> classes.

Or it's a good argument for an implementation of Element that doesn't
use 7 instance variables but keeps the same API.  That's the approach I
prefer.

> JDOM is designed to implement an XML document object model in Java.
> Having a final equals method is not essential for this goal and 
> losing it is not a big loss.

OK, how does getMixedContent().remove(comment) work?  If Comment could
be implemented with an equals() method that declares comments are
equivalent if their content is equivalent, then that call will sometimes
remove the wrong element.  Having equals() final enforces correct
semantics.

> Firstly the code:-
> 
> Document d = builder.getDocument()
> 
> is not speaking in terms of concrete classes. Document could be
> abstract.

But if Document is abstract, then 

Document d = new Document() 

won't work.

> Sure I just wanted to highlight the fact that the current sample
> programs concentrate on reading / parsing rather than custom
> construction. Parsing and reading of XML appears much more common 
> than custom building. 

I think that's a leap.  If you just wanted to parse and read, not
manipulate or output, and your documents are big enough to the point
where memory use is a concern, I would encourage people to use SAX.

Anyway, your email goes on but I've said everything I have time to say
today.

-jh-