Community
Participate
Working Groups
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.
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...
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.
Too much to do and this has little benefit.
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.
I think this feature request was implemented via Bug 519572.
*** This bug has been marked as a duplicate of bug 519572 ***
