[jdom-interest] Text class in the api

[Alex Rosen]

> 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.

Isn't that char[] the internal buffer of the parser, that gets reused? If
so, then there needs to be an allocation and copy, whether this gets done
internally by String(char[]) or StringBuffer.append(char[]), or we do it
manually. The comment about synchronization is a good one, but supposedly
the penalty for sychronized methods is negligible with HotSpot. Doesn't seem
worth it to basically rewrite StringBuffer inside of Text.

> 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.

That sounds like the right approach to me.

Alex