[jdom-interest] cvs.jdom.org is down. When will it be back

[Malachi de AElfweald]

Ah, I don't think I have tried that....

Looking at the code, setLength() calls copy() IF shared
toString() calls new String(StringBuffer)
which in turn calls StringBuffer.shared = true

SO....
calling toString() THEN setLength() is what is causing the problem

now, odd enough, copy simply creates a new buffer of the SAME SIZE
and fills it via System.arraycopy....

so, the problem MIGHT be in that call...  basically, your calls below does
a System.arraycopy(currentContents, 0, newContents, 0, valueFromSetLength)

so, we should be able to determine if that is the problem by calling
System.arraycopy with length=0 with something other than 
String/StringBuffer...

Malachi


On Fri, 20 Dec 2002 22:09:02 -0600, Bradley S. Huffman 
<hip at a.cs.okstate.edu> wrote:

> Malachi de AElfweald writes:
>
>> I'm curious... I have seen many references to the "StringBuffer 
>> error".... but,
>> I have not yet experienced anything... what exactly is this bug?
>
> As I recall it was using StringBuffer as a reusable buffer. As in
>
> StringBuffer buffer = new StringBuffer(1024);
>
> // store stuff in buffer
>
> String a = buffer.toString();
> buffer.setLength(0);
>
> Now if you reuse the buffer, thinking you still have 1024 char allocated,
> you'd be wrong. Either toString or setLength reallocates StringBuffers
> internal array to it's default size (which at think is 16).
>
> Brad
>
>



--