[jdom-interest] building jdom trees

[GB/DEV - Philip Nelson]

> Probably a silly question, but SAXHandler creates Element 
> objects directly
> via new, so is it not possible to build a JDOM tree which 
> contains Element
> subclasses? Do I have to build the JDom tree then create some 
> sort of clone
> which adapts each Element to the interface I need?
>

I agree with you that it should be possible to use a subclass of SaxHandler
from SaxBuilder.  I seem to remember Jason agreeing with that point not so
long ago.  With a SaxHandler subclass, you could easily integrate your own
Element, Attribute subclasses though the effort would still end up
re-implementing significant numbers of methods.

So far I have used an approach something like (but not exactly like) the
Decorator pattern

Element enhancedElement =  new MySubclass(originalElement);

It can work via delegation most of the time, but that means a lot of coding.
As more pieces of Element become Protected, this may be a little easier to
do but riskier I suppose.  It has only worked for simple behaviour changes
though and I don't think it would be a viable option most of the time unless
Element itself was designed as a decorator.

> 
> Also Element::equals(Object) is final and uses "==", which 
> means I can't
> change it; this is presumably a necessity I shouldn't change?
> 
Search the list, it has been discussed fairly often, though I don't remember
the discussion ;^(

> I have a tendency to write element.getChildren().get(i) and 
> suchlike, I
> notice that getChildren() builds a PartialList each time so 
> obviously this
> is inefficient (actually I guess LinkedList.get(i) also loops 
> and I should
> use an iterator?); is there a set of performance hints anywhere?

I think this feature is a nice feature of JDOM.  I've just started to do a
little profiling and this has not jumped out at me so far, but I wasn't
looking for that either.

What has jumped out at me though is how often we use String.equals but that
is a different story.