[jdom-interest] Re: SAXBuilder enhancement request /2

[philip.nelson at omniresources.com]

> --- philip.nelson at omniresources.com wrote:
> [whitespace trimming]
> > Yup.  We already had this discussion and determined that trimming 
> > whitespace was too easy to do without cluttering the api.  
> Again that 
> > mythical helper class in jdom-contrib if anybody really wants to...
> 
> But what if trimming-while-building can make the build process faster?

That could be a good thing and I'm all for somebody coming up with a good
filter.  Looks like we already agree that we wouldn't need to change the api
for that.  But, that isn't quite the same as adding some soft of trim method
to element.

On the issue of speed.  The fastest thing I ran across that would work for
building a JDOM document was to use the sax 1.0 version of MinML.  JDOM no
longer has a way to work with that sax api but I rolled my own in a couple
of hours.  The speed gain was great, ~50% as I recall.  Of course you have
to live without whitespace for the most part, namespaces, mixed content of
any sort and probably other shortcomings you may not be able to live with. 

Christian Gross was talking last year at SDExpo about a similar approach to
speed.  He got his application working with a standard parser.  Then he took
the parser (Expat I think) and just started ripping it apart for things he
didn't need.

This idea of using a filter makes sense but *maybe* what most of us data
oriented folks probably need is a faster and simpler parser that we could
use when appropriate for our apps.