[jdom-interest] Re: [jdom-announce] JDOM Beta10 released

[Bradley S. Huffman]

phil at triloggroup.com writes:

> I'm very pleased to see that JDOM is being officially released soon. Mo=
> reover, it features new capabilities like Content class that will make =
> our work easier!
>
> I still have just one concern with the API, that forces us to provide o=
> ur own build to customers. It's about optimization, when you want to co=
> nstruct a DOM without going through any validation stuff, because you p=
> erfectly know that your DOM is valid. Typically, we currently do this w=
> hen building an HTML tree programmatically (the build class is machine =
> generated from HTML source). 
> We already spoke about this earlier, and I want to reanimate the debate=
> because it may gain up to 20/25% execution speed. 
>
> You'll find a copy of the changes I made and now working with Beta 9 in=
>  production. To please Eliott and prevent people from doing something b=
> ad, all these "unverified" methods must be called as static m=
> ethods from UnverifiedFactory class. I joined to the mail the pieces of=
>  code that does the trick.  Nothing changed in the API, it is just an a=
> dd-on.. Because of class scopes, there is now way to make it running wi=
> thout providing a custom build. 

Jason just moved JDOMFactory out of package org.jdom.input and into
org.jdom so users can have a custom factory to skip verification from
trusted sources, so that pretty much eliminates the need for the extra
createElement, etc. methods.  And since it has moved, putting a "fast"
version of JDOMFactory in contrib would probably be a good idea at this
point.

But I don't see how the static addContent methods help.  Elements can have
anything as children except a DocType so all your skipping is one instanceof
test and a check for a null parent.  But the potentially biggest time waster,
reallocation of the content array, remains intact. But that assumes the
number of children in most of a document's elements greatly exceeds the
INITIAL_ARRAY_SIZE and causes excessive array reallocation. Something only
profiling can support or disprove, and then only on a case by case bases.

One problem I do see, which falls under the TODO item "ensure JDOM is
appropriately tweaked for subclassing", is if your problem would benefit
from a larger INITIAL_ARRAY_SIZE, I don't see a easy to do it currently.

Brad