On older JVM's (SUN<1.4 as far as I remember) String.intern was relatively slow.
I did some tests some time ago and using a HashMap would be faster!
You may want some fallback in case your JVM has a poor String.intern implementation.
This kind of code duplication can IMHO only be avoided, in case you have a strict policy in place. Someone would need to constantly monitor the Eclipse project for code duplication, and maybe also check for code duplicates during code reviews.
Anyway I wonder whether code bloat is really the problem with Eclipse.
Do we have numbers about how much code is loaded and how much memory it consumes?
Or is it "only" a psychological problem?
How does it compare with the actually memory allocated for objects?
I would guess if the goal is that we want to scale in a multiuser enviroment, then I would guess that this is more important.
On Thu, Oct 16, 2008 at 11:42 AM, James Blackburn <jamesblackburn@xxxxxxxxx>
Your ctrl-shift-T is a good illustration of 'code bloat' ;)
On Wed, Oct 15, 2008 at 3:08 PM, <Mark_Melvin@xxxxxxxx
> I think something similar already exists in the platform but is internal.
> I'm not sure how stable/useful it is but Ctrl+Shift+T for "StringPool".
For me that brings up:
All of which are identical.
Eclipse then has a org.eclipse.core.internal.utils.StringPoolJob which
calls 'shareStrings(StringPool)' on participating
IStringPoolParticipants. Given that StringPool.add() uses a HashMap
to reimplement String.intern() I wonder what the performance
difference is between StringPool and String.intern()...