Bug 46613 - AST nodes and string buffers
Summary: AST nodes and string buffers
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.0   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 3.0 M6   Edit
Assignee: Olivier Thomann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-11-13 14:12 EST by Jim des Rivieres CLA
Modified: 2003-12-17 07:16 EST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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