Adding a fixate method to StringBuilder and StringBuffer.

[Jesús Viñuales]

Paolo,

Look at this bug evaluation
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6219959 to get further
information about what Tom told you yesterday.

I'm afraid that there is nothing to do here... because an optimization based
on buffer-sharing + copy-on-write has several problems (although I'm sure
that with the "new" memory model, a redesign based on a volatile flag would
solve the concurrency problems) and *surprisingly* seems not to give any
performance gain at all!! (surely because of the overload for the GC).

Last autumn I tried (for fun) several solutions (even tried a completely
internal redesign of StringBuilder based on appending in a String list
instead of arraycopying to a char buffer) but had no luck.

It would be great that some brilliant brain would be able to optimize, it
but seems difficult/impossible or at least I think that this has no priority
:-(

Regards,
Jesús

> Tom Hawtin wrote:
> 
> 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