[jdom-interest] Text class in the api
arosen at silverstream.com
Wed Oct 24 08:07:15 PDT 2001
> 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.
> 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.
More information about the jdom-interest