Paulo Levi wrote:
Since CharSequence is obviously flawed in that it doesn't allow
efficient read-only views because of a missing method, there are various
methods in the jdk where a stringbuilder/buffer is built, populated and
then toString()-ed and left to be garbage collected. I'm seeing places,
especially in the Document classes, where this originates a OutOfMemory
exception, because the second buffers can't be created concurrently.
I'm asking for a
public final String fixate()
method for both stringbuffer and builder that reuses the internal char
array on a private String constructor (that takes the array), and sets a
flag to never allow the buffer to be modified again.
But what i would really like is that the CharSequence interface would
altered. CharSequence2.
This is the way StringBuffer worked prior to 1.5. That produced so many
problems. It is widely known that 1.4 still suffers from unsafe
publication issues (not that 1.4 *spec* has a sensible memory model at
all). Obviously for StringBuilder, without synchronisation, it is way out.
Swing text classes, used reasonably, should not result in
OutOfMemoryErrors. If you require to have lots of Strings sharing the
same backing buffer, in Sun's current implementation you can use
toString once followed by many String.substrings. Other
performance-optimised implementations have different behaviour. If exact
behaviour is important to you, then you will need to use your own
immutable char[] wrapper class.
Tom Hawtin
