[jdom-interest] DOMBuilder

[Rosen, Alex]

We are a 10 person team who have been using JDOM for the past 3 or 4 months. I
just searched our codebase for DOMBuilder and found 4 instances.  (They are
using the Xerces DOMParser to parse an XML file into a DOM tree, and then
DOMBuilder to parse this into a JDOM tree.) This is a terrible waste of
resources, to be using DOMBuilder instead of SAXBuilder. I'd really, really
like to get rid of them.

3 of the instances are setting up Xerces-specific features on the DOMParser, so
they can't currently be converted to use SAXBuilder. I mentioned this problem a
few weeks ago, and got this response:

> "Rosen, Alex" wrote:
> >
> > Wouldn't it be nice if there were a version of SAXBuilder that took an
> > already-created XMLReader? Currently there doesn't seem to be a way that I
can
> > turn on arbitrary SAX features that aren't supported by the SAXBuilder API.
I'd
> > like to create an XMLReader myself, set it up however I'd like, and give it
to
> > SAXBuilder.
>
> The reason we've elected not to do that is that many features of the
> XMLReader need to be set a certain way for SAXBuilder to function.  If
> you passed in an XMLReader we'd have to either take on faith that the
> features were set properly (not a good solution, as our feature
> selection may change over time without changing the API) or set the
> features to guarantee proper functioning (not good either, as it changes
> the passed-in parameter as a side effect).

Jason, I agree that neither of these is great. But the alternative is to force
people to use DOMBuilder, which is even worse. I think this will slow the
acceptance of JDOM, as people either realize what a waste of resources this
would be, or don't realize and do it anyway, resulting in poor performance.

In the 4th instance, we were using DOMBuilder for no good reason at all. If
people do this accidentally, they'll also get poor performance and not think
highly of JDOM. If we make the change I suggest above, I also propose changing
the name of the 3 DOMBuilder.build() methods that are listed as being for
debugging only, so it's harder to make this mistake. E.g. debugBuild() or
something. This will make it more obvious to avoid them, and if they are
deprecated and eventually removed, it will red-flag the cases where the code
can be made much more efficient by using SAXBuilder instead.

Alex Rosen
SilverStream Software