[jdom-interest] Text class in the api

[philip.nelson at omniresources.com]

> I agree, this would be a good time to go down the Text node 
> route and see
> what happens.
> 
> This info certainly puts a hole in my String vs. StringBuffer argument
> (http://www.servlets.com/archive/servlet/ReadMsg?msgId=8776&li
> stName=jdom-in
> terest). I was assuming that characters() was called multiple 
> times only if
> the character data was longer than the parser's internal 
> buffer, but I guess
> that's wrong. Bummer.

I think in many/most cases you would be correct.  Apparently there are cases
where it's not true though.

> 
> > There are other ways to do this of course, but I think using
> > a Text class
> > has advantages.  We might consider implementing the Text
> > internal storage as
> > char[] instead of String or StringBuffer.  By doing this, we
> > could get the
> > fast(er) append functionality of StringBuffer but near the
> > efficiency of
> > String which would still be the most common use case.
> 
> When would char[] be faster than StringBuffer?

I am *theorizing* that if Text was based on char[], append would work as
well as StringBuffer, possibly faster because we wouldn't have to have
syncronized methods.  Marginal difference quite possibly.  StringBuffer
doesn't have a constructor for char[], int, int, unlike String. In the most
common case where the full text content of an element arrives in one
characters() call, a char[] implementation wouldn't have to allocate extra
space, which I think StringBuffer does by default.  If we want to allocate
extra space, this could be set as a property or in a resource bundle.
toString() would be about the same as StringBuffer most likely.

Thinking about this, is seems that if we took the existing starter code,
based on StringBuffer, added append and constructor signatures that accepted
char[], int, int, we could modify it further down the road.  Might get us
there faster.

opinions?