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

Malachi de AElfweald malachi at tremerechantry.com
Sat Dec 21 02:01:14 PST 2002

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

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 


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


More information about the jdom-interest mailing list