Clearly I wouldn't have gone to all this trouble unless I was
fixing a real problem, but I didn't keep any notes on how I reached
this conclusion. Is it the case that if you intern a string for
the first time, and that string has internal fragmentation, that
the whole space-wasting string gets interned? Anyone have a
reference on that issue?
The Javadoc for intern() states:
"When the intern method is invoked, if the pool already contains a
string equal to this String object as determined by
the #equals(Object) method, then the string from the pool is
returned. Otherwise, this String object is added to the
pool and a reference to this String object is returned"
The way the documentation says "this String object is returned"
suggests that the following code would (a) run without an exception,
and (b) cause unwanted character data to end up in the String pool.
String bigString = "349ilskjnv,.zjshr,mscbv";
// subString still contains all of bigString's char array, just
different offsets.
String subString = bigString.substring(2, 8);
String interned = subString.intern();`
if (subString != interned) throw new Exception("Should have interned
the 'this' object...");
Testing this code on the Mac with Java 1.5.0_07-164, the interned
value is in fact a completely new string, created at the time that
intern() was called with the char array properly reduced. The
following bug suggests this has been the case for a while:
(Also, for as long as I can remember, new String(otherString) is
sufficient to trim the size of a String's internal array...)
C
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/java-dev/email@hidden
