[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();
> 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).
More information about the jdom-interest