6

Ok, this question is an extension of this question

Java Strings: "String s = new String("silly");"

The above question asked the same question as this one, but I have a new doubting point.

According to Effective Java and the answers of above question, we should not do String s = new String("a new string");, because that will create unnecessary object.

I am not sure about this conclusion, because I think Java is doing automatic string interning, which means for a string, anyway there is only one copy of it in the memory.

So let's see String s = new String("a new string");.

"a new string" is already a string which has been created in the memory.

When I do String s = new String("a new string");, then the s is also "a new string". So according to automatic string interning, s should be pointed to the same memory address of "a new string", right?

Then how can we say we create unnecessary objects?

Community
  • 1
  • 1
Jackson Tale
  • 25,428
  • 34
  • 149
  • 271
  • 9
    There *is* only one copy of the String *unless you do `new String(...)`*. Don't do it unless you have to. – Hovercraft Full Of Eels May 19 '12 at 15:30
  • +1 for interesting question, never thought about it. However, most of the time you can check this stuff by looking into the differences (or lack of differences) in bytecode between the 2 versions. – Radu Murzea May 19 '12 at 15:32
  • 6
    `intern`ing is only automatically performed on `String` literals. – Jeffrey May 19 '12 at 15:39
  • 2
    Because there's another string, that's what `new` does. – Dave Newton May 19 '12 at 15:41
  • 2
    What makes you think that `new String("a new string")` is better than `"a new string"`? I can't understand why you want to use the former. – David Heffernan May 19 '12 at 15:41
  • @DavidHeffernan no I am not saying i prefer and I am just wondering whether the statement `we should NOT do that` is true or not. Also, if `new string("a string")` is so bad, why doesn't Java simply remove this constructor? – Jackson Tale May 19 '12 at 15:48
  • You can do it if you want. Nobody dies if you do. You just create extra objects that aren't needed. – David Heffernan May 19 '12 at 15:53
  • @DavidHeffernan: I disagree. A puppy is killed every time this is done. I know this for a fact. – Hovercraft Full Of Eels May 19 '12 at 15:57
  • @HovercraftFullOfEels I guess that is meant to be funny. But really, do you believe that it ever really matters that much? Presumably you have evidence. I mean, I wouldn't use new to create strings but I think it would be hard to come up with a scenario where it actually mattered. – David Heffernan May 19 '12 at 16:00
  • @DavidHeffernan: nah, it doesn't matter that much, unless the code is creating a lot of String objects in a tight loop, and then object creation can be somewhat expensive. It's just a good habit to avoid creating new Strings so as to not run into this problem inadvertently. – Hovercraft Full Of Eels May 19 '12 at 16:07

3 Answers3

16

String a = "foo"; // this string will be interned
String b = "foo"; // interned to the same string as a
boolean c = a == b; //this will be true
String d = new String(a); // this creates a new non-interned String
boolean e = a == d; // this will be false
String f = "f";
String g = "oo";
String h = f + g; //this creates a new non-interned string
boolean i = h == a // this will be false
File fi = ...;
BufferedReader br = ...;
String j = br.readLine();
boolean k = a == j; // this will always be false. Data that you've read it is not automatically interned
Christoffer Hammarström
  • 27,242
  • 4
  • 49
  • 58
ControlAltDel
  • 33,923
  • 10
  • 53
  • 80
2

You may want to read more about String literal pool in JVMs. Quick googling pointed me to this article: http://www.xyzws.com/Javafaq/what-is-string-literal-pool/3 which seems quite valid.

Also you may be interested in Integer literal pooling as well as other literals pooling in Java.

Yuriy Nakonechnyy
  • 3,742
  • 4
  • 29
  • 41
0

using "=" instead of "=new String" is better since it might result in a single instance instead of multiple instances.

android developer
  • 114,585
  • 152
  • 739
  • 1,270