Bug 46613

Summary: AST nodes and string buffers
Product: [Eclipse Project] JDT Reporter: Jim des Rivieres <jeem>
Component: CoreAssignee: Olivier Thomann <Olivier_Thomann>
Status: VERIFIED FIXED QA Contact:
Severity: normal    
Priority: P3    
Version: 3.0   
Target Milestone: 3.0 M6   
Hardware: All   
OS: All   
Whiteboard:

Description Jim des Rivieres CLA 2003-11-13 14:12:45 EST
Build I20031111

Explicit String allocations were recently removed from AST.toString 
and elsewhere. They were there for good reason (as the comment there 
suggested). The problem is that new String(stringBuffer) is not quite 
equivalent to StringBuffer.toString(). See the note to implementors on 
StringBuffer.toString(). 

The upshot is that a snippet like

StringBuffer sb = new StringBuffer(6000);
sb.append("foo");
return sb.toString(); 

will typically return a String object that occupies the space of a 6000 
character string rather than a 3 character one.

return new String(sb);

allocate a new string of exactly the right size.
Comment 1 Jim des Rivieres CLA 2003-11-13 14:13:25 EST
Incorrectly entered. Moving to JDT Core.
Comment 2 Olivier Thomann CLA 2003-11-24 10:08:34 EST
StringBuffer.toString() calls new String(sb). So I really don't see any memory
improvement. We could get a small improvement in time.
Comment 3 Jim des Rivieres CLA 2003-11-24 12:45:40 EST
You're quite quite. The Sun implementation of both "sb.toString()" and "new 
String(sb)" are equivalent and return a String object that occupies space 
proportional to sb.capacity().

On the other hand, "sb.substring(0)" returns a String object with space 
proportional to sb.length().
Comment 4 Olivier Thomann CLA 2003-11-24 12:55:00 EST
So I guess you'd like the latter to be used.
Comment 5 Olivier Thomann CLA 2003-11-25 12:00:02 EST
I will get rid of new StringBuffer(6000); and replace it with new
StringBuffer(). Then we use the default behavior of the StringBuffer.

Fixed and released in HEAD.
Comment 6 David Audel CLA 2003-12-17 07:16:41 EST
Verified for 3.0M6