Use of the String(String) constructor in Java [duplicate]

I've read on articles and books that the use of String s = new String("..."); should be avoided pretty much all the time. I understand why that is, but is there any use for using the String(String) constructor whatsoever? I don't think there is, and don't see any evidence otherwise, but I'm wondering if anyone in the SO commmunity knows of a use.

Solution 1:

This is a good article: String constructor considered useless turns out to be useful after all!

It turns out that this constructor can actually be useful in at least one circumstance. If you've ever peeked at the String source code, you'll have seen that it doesn't just have fields for the char array value and the count of characters, but also for the offset to the beginning of the String. This is so that Strings can share the char array value with other Strings, usually results from calling one of the substring() methods. Java was famously chastised for this in jwz' Java rant from years back:

The only reason for this overhead is so that String.substring() can return strings which share the same value array. Doing this at the cost of adding 8 bytes to each and every String object is not a net savings...

Byte savings aside, if you have some code like this:

// imagine a multi-megabyte string here  
String s = "0123456789012345678901234567890123456789";  
String s2 = s.substring(0, 1);  
s = null;

You'll now have a String s2 which, although it seems to be a one-character string, holds a reference to the gigantic char array created in the String s. This means the array won't be garbage collected, even though we've explicitly nulled out the String s!

The fix for this is to use our previously mentioned "useless" String constructor like this:

String s2 = new String(s.substring(0, 1));  

It's not well-known that this constructor actually copies that old contents to a new array if the old array is larger than the count of characters in the string. This means the old String contents will be garbage collected as intended. Happy happy joy joy.

Finally, Kat Marsen makes these points,

First of all, string constants are never garbage collected. Second of all, string constants are intern'd, which means they are shared across the entire VM. This saves memory. But it is not always what you desire.

The copy constructor on String allows you to create a private String instance from a String literal. This can be very valuable for constructing meaningful mutex objects (for the purposes of synchronization).

Solution 2:

If I remember correctly the only 'useful' case is where the original String is part of a much larger backing array. (e.g. created as a substring). If you only want to keep the small substring around and garbage collect the large buffer, it might make sense to create a new String.

Solution 3:

Just to expand on Douglas's answer*, I can give a firm example of where I've used it. Consider reading a dictionary file, with thousands of lines, each one of them just a single word. The simplest way of reading this is to use BufferedReader.readLine().

Unfortunately, readLine() allocates a buffer of 80 characters by default as the expected line length. This means that usually it can avoid pointless copying - and a bit of wasted memory isn't normally too bad. However, if you're loading a dictionary of short words in for the duration of the application, you end up with a lot of memory being permanently wasted. My "little app" sucked up far more memory than it should have done.

The solution was to change this:

String word = reader.readLine();

into this:

String word = new String(reader.readLine());

... with a comment, of course!

* I can't remember whether I was working with Douglas when this actually cropped up, or whether it's just coincidence that he answered this particular question.