Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 367705

Summary: Prefer StringBuilder to StringBuffer
Product: [Modeling] EMF Reporter: Ed Willink <ed>
Component: CoreAssignee: Ed Merks <Ed.Merks>
Status: CLOSED DUPLICATE QA Contact:
Severity: enhancement    
Priority: P3 CC: Lars.Vogel
Version: 2.7.0   
Target Milestone: ---   
Hardware: PC   
OS: All   
Whiteboard:
Bug Depends on:    
Bug Blocks: 364806    

Description Ed Willink CLA 2012-01-02 08:22:50 EST
From StringBuilder JavaDoc:

 * As of  release JDK 5, this class has been supplemented with an equivalent 
 * class designed for use by a single thread, {@link StringBuilder}.  The 
 * <tt>StringBuilder</tt> class should generally be used in preference to 
 * this one, as it supports all of the same operations but it is faster, as 
 * it performs no synchronization.

The genmodel'd toString methods use StringBuffer.
Comment 1 Ed Merks CLA 2012-01-04 02:34:45 EST
Certainly this is an enhancement request, not a bug.

Even then you have to question the merit of this.  We still support generating code that will run with JDK 1.4, so the templates would have to be conditional on the Compliance Level, i.e., they'd get even more complicated.  Of course most folks target 1.5 or higher, so then we need to question if all clients want to be in the position of regenerating all their model to change from StringBuffer to StringBuilder.  Some might complain that it should be optional.  Do we need yet another option?  I hope not.  Then you have to question the value of the alternative.  Is the performance of toString important to any client.  It's hard to imagine that being the case.  So what's the substantial benefit?

It's easier to argue that performance critical parts of the runtime (which are those?) should make such changes...
Comment 2 Ed Willink CLA 2012-01-04 03:21:11 EST
The performance impact seems limited to default, marginally readable, toString() which shouldn't really be on critical paths.

I see the main motivation as educational. I probably learnt to use StringBuffer() from EMF, so it would good if EMF set a good example.

This could be deferred until 1.4 support is terminated or realised by a genmodel getStringBuilderClassName() helper function.
Comment 3 Ed Merks CLA 2012-10-05 01:39:50 EDT
Too much to do and this has little benefit.
Comment 4 Lars Vogel CLA 2017-06-07 14:57:25 EDT
I'm in the process of getting rid of StringBuffer in Platform UI code. Please reconsider this enhancement request, it would be great if EMF could use StringBuilder these days. 

I think in 2017, we can assume that new code is above the unsupported 1.4 version.
Comment 5 Lars Vogel CLA 2018-01-22 07:25:00 EST
I think this feature request was implemented via Bug 519572.
Comment 6 Ed Merks CLA 2018-01-22 07:35:27 EST

*** This bug has been marked as a duplicate of bug 519572 ***