About Strings and Memory

Question

Let's look at a couple of examples of how a String might be created, and let's further assume that no other String objects exist in the "String constant pool"l:
String s = "abc"; //   creates one String object and one
                  //   reference variable In this simple case, "abc" will go in the pool and s will refer to it.
   String s = new String("abc"); // creates two objects,
                              // and one reference variable In this case, because we used the new keyword, Java will create a new String object
in normal (nonpool) memory, and s will refer to it. In addition, the literal "abc" will
be placed in the pool.
My question is this:
Then why did the sun developers created the 'public String(String str)' constructor even it uses an additional memory?

Answer 1

Caarmel wrote:
Let's look at a couple of examples of how a String might be created, and let's further assume that no other String objects exist in the "String constant pool"l:
String s = "abc"; //   creates one String object and one
//   reference variable In this simple case, "abc" will go in the pool and s will refer to it.Nope. Executing that line only assigns a reference to an already existing String into the variable. The constant was put into the pool when the class was loaded. So your initial assumption of no Strings in the constant pool is invalid.
   String s = new String("abc"); // creates two objects,
// and one reference variable Nope. As above, it creates one object. The other already existed.
Then why did the sun developers created the 'public String(String str)' constructor even it uses an additional memory?First, note that your question really has nothing at all to do with the constant pool. Your question is really "Why does the String(String) constructor exist, given that String is immutable, and given that we can just do s2 = s1?" That question applies even in complete absence of the constant pool.
I wasn't there when they made the decision, so I can't tell you what their thinking was. I can tell you one case where it's useful, however.
String s1 = some_very_long_string;
String s2 = s1.substring(x, x + a_small_number);
String s3 = new String(s1.substring(x, x + a_small_number);Both the s2 and s3 lines create new String objects. However, in the case of s2, the new object shares the same char array as the original, whereas in the s3 case, a new backing array of just the right size is created. If s1 is very large, AND if the substring we're extracting is very small, AND if the substring needs to live on significantly longer than the original, then without the explicit new String(), even though we only need a few characters and could get away with a very small char array, we end up stuck with a large char array that can't be GCed even when the original String is.
So in this rather unlikely scenario, we can avoid wasting a bunch of memory that can't be GCed when we only need a small fraction of it.
Or maybe the constructor came about in early versions, before other aspects of the language making it mostly useless were solidified, and then it was kept for backward compatibility.
Or maybe they didn't really have a good reason and just figured it made sense to have a copy constructor.
Or maybe the reasons that make it mostly redundant are implementation details, and they wanted to provide a copy constructor so that as Java evolved, if the implementation changed, the functionality would still be there.
Or maybe none of the above.