Gap Buffer based AbstractStringBuilder implementation
Thomas.Hawtin at Sun.COM
Sun Nov 22 07:55:11 UTC 2009
Osvaldo Doederlein wrote:
> Looks like good stuff. And it remembers me from another old issue:
> patterns of code that demand data copying that could often be avoided.
> Every StringBuffer/StringBuilder is ultimately consumed by a toString()
> invocation to produce the result String, and in 99% of all uses, only
> one such String is produced and the buffer object is immediately
> discarded. So, toString() could pass the internal char to the String
> constructor, instead of forcing its copy. The API is coded
> conservatively to always do that copy, because in 1% of cases people
There is a security issue there. When multiple threads are involved, it
is possible (though not necessily easy) to create a mutable String if
the backing char is shared.
More information about the core-libs-dev