[...]

While i consider such things implementation details of
java.lang.String, and therefore not really my concern, the new
behaviour is more in line with the "reasonable expectations" of most
programmers. If i create a new object, i expect its storage to be
allocated somewhere. Also, if i drop a reference to a very long string,
but retain a tiny subsection, i expect to be able to drop all but the
small subsection.

The substring created will share the underlying char[] array.

To the best of my memory that has always been the behavior.
Unfortunately, I don't have source from a JDK before 1.4.2 handy to
check.

   -- chris

This seems to come up every once in a while.

This is a call to a private constructor inside the String class, which
reuses the underlying char[].  It does not do the same thing as the
public String(String) constructor, which copies the underlying data.  So
when people say that "new String" copies the underlying char[], you
should only apply that statement to the String(String) overloaded
constructor, and not to the String(int,int,char[]) private overload used
there.

...snip Sun's implementation...

Note which constructor this invokes: String (int, int, char[]).  Sun's
implementation of substring, at least as of 1.5.05 and as far back as I've
been using Java, shares the char[] containing the String's characters
on calls to substring.  It still pins the underlying char array, and is
still cheap both computationally and memory-wise if the originating
string's lifespan is at least as long as those of the substrings.

On Sat, 14 Jan 2006 07:36:33 GMT, Roedy Green
<my_email_is_posted_on_my_website@munged.invalid> wrote, quoted or
indirectly quoted someone who said :

here is my latest understanding:

substring is clever. It does not make a deep copy of the substring the
way most languages do. It just creates a pointer into the original
immutable String, i.e. points to the value char[] of the base string,
and tracks the starting offset where the substring starts and count of
how long the substring is. This could be confusing if you were
low-level debugging since you would see the whole String, not just the
substring. There were reports of a bug in Microsoft's implementation
of substring. The downside of this cleverness is a tiny substring of a
giant base String could suppress garbage collection of that big String
in memory even if the whole String were no longer needed. (actually
its value char[] array is held in RAM; the String object itself could
be collected.)

It is probably still a good idea to use indexOf( lookFor, offset )
with a rather than creating a substring first and using indexOf(
lookFor ) on that.

If you know a tiny substring is holding a giant string in RAM, that
would otherwise be garbage collected, you can break the bond by using
littleString = new String( littleString ) which will create a new
smaller backing char[] with no ties to the original String.

If you are a curious sort, and study the code for String. substring in
src.zip, this sharing logic might not be apparent. The key is a
non-public String constructor that takes parameters in the reverse of
the usual order String (int offset, int count, char value[]).