Strings are constant; their values cannot be changed after they are created. String buffers support mutable strings. Because String objects are immutable they can be shared.
I think that means that if you instantiate a string identical to an existing one, the JVM may share the instance. However, I would not depend on that an I would always use .equals (someOtherString) method to compare two string references. [ May 24, 2004: Message edited by: Eddie Vanda ]
The nice thing about Standards is that there are so many to choose from!
Actually, there's no question about it. The behavior is precisely defined.
Every time you use "new String()", a new String will be created.
String literals, however (i.e., "abc") are indeed shared. If the quoted String "abc" appears 10 times in the classes loaded by the JVM, there will be only one String object that represents these ten literals. So saying
String s = "abc";
will never create a new String object.
You should essentially never use
String s = new String("abc");
There are a few very specialized circumstances where it can make sense, but in the general case, and unless you know otherwise, you're just wasting resources. None of these special cases, by the way, involves passing a literal as the argument -- only another String variable.
If I'm reading some code and I see 'new String("abc")', that always makes me think that the programmer was fairly new to Java.
Indeed, the idea of immutability prevents any String object from changing. All that changes are the reference variables. So, in the above case, "lostReference" will essentially be lost in memory (assuming no other references point to it), until the garbage man comes along and cleans it up. [ May 24, 2004: Message edited by: Jeffrey Hunter ]
author and iconoclast
Originally posted by Jeffrey Hunter: [CODE] So, in the above case, "lostReference" will essentially be lost in memory (assuming no other references point to it), until the garbage man comes along and cleans it up.
Well, no, actually. That's yet another complication: literals are held in a special string pool, and are thus always referenced. A String literal won't be garbage collected.
Joined: Apr 16, 2004
From what I understand, this depends on the specific JVM implementation. In large part, string literals in the constant pool are transparent, and not eligible for GC. However, certain JVMs (such as those which are space-optimized for mission-critical systems), may define references to string literals as opaque, and thus they become eligible for GC. The JVM specification is not concrete when defining a specific GC algorithm, so essentially the answer to this problem is one of those, it depends.
To clarify a question: you said "...if i changed the value of str="def"..."
you cannot change a String. So if you say str="def", what is happening is that the reference str now points to a different string. If "def" was not already in the string pool, it will be created; but now str points to it. You cannot change a string.
Hi, I am a student who has studied JAVA just 3 months... My teacher told me that if we use then JAVA will find "abc" in the "String Pool",and refer A to "abc" in the pool.
if we use JAVA will create a new String object on "heap".
But I am still confused... Does it mean that if I use and there will be TWO String object on the heap?? and Will String objects in the heap be Garbage collected if there is no reference refer to them? [ May 25, 2004: Message edited by: XinJi Chang ]
here will be TWO String object in the heap?? and Will String objects in the heap be Garbage collected if there is no reference refer to them?
the answers are yes, and sort-of. you will have two separate objects on the heap, and two references (B and C). so if you use B==C, you will get false, but B.equals(C) will give true.
the second question gets a "sort-of", because you can never say something "will be" collected by the GC. they become ELLIGIBLE for GC, but that may or may not ever occur. There is no way of knowing what happens (short of special tools) or controlling it.
There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors