Are string literals garbage collected?

[Jonatan Samoocha]

After having consulted several books and threads on this forum, it is still unclear to me how the garbage collection mechanism works on String literals. More generally: Do objects in the literal pool become eligable for garbage collection? (before the JVM exits, of course).
For example, in the following sample:

public class Test{
    public static void main(String[] args) {
        foo();
        System.out.println("foo() ended"); //5
    }
    public void foo() {
        String s1 = "String Literal"; //*
        String s2 = s1; //1
        s1        = null; //2
        System.out.println(s2); //3
        s2        = null; //4
        System.out.println("No references to String Literal");
    }
}

does the string literal at the marked line become eligable for garbage collection? If so, at which line?
Can anyone point me to detailed rules about this topic? Thanks in advance,
Jonatan

[Peter den Haan]

String literals are never garbage collected. The JVM specification will tell you that String literals are part of the runtime constant pool, which is distinct from the heap where the garbage collector does its job.
- Peter

[Vikrama Sanjeeva]

Peter i do agree with you at this point that String Literals are Not Garbage Collected.As mentioned clearly by JLS.But the problem still exist that why many mocks including some good mocks ask the questions like the one which Jonatan mention.What is the solution.And does SUN can ask or asks this type of questions?.
Bye.
Viki.
------------------
Count the flowers of ur garden,NOT the leafs which falls away!

[Valentin Crettaz]

Vikrama, Sun's exam will conform to what the JLS says, don't worry ! The questions in the mocks that don't are bad questions and you shouldn't pay attention to them
------------------
Valentin Crettaz
Sun Certified Programmer for Java 2 Platform

[Jose Botella]

Hello EveryBody
To see how String literals are not eligable for g.c make a WeakReference to point one of them, call the g.c. and later call get on the WeakReference to see how it is still returning a reference to the String literal.
By the end of October I posted an example, search by Botella to see it.
Hello Peter
The CONSTANT_String_info in the constant pool is not a String literal, neither a String, it is not an object. It is a symbolic reference that points to the content of a String object that will be created when the JVM resolves the constant pool entry. That is refered to in the JVMS as "derive".

[Ragu Sivaraman]

Yeah i did come across these issues and many times i got it wrong
when i choose "string litreal wont be gc'ed" since
the mock exams keys says "the string literal will be gc'ed" becoz they are created using new operator for the first time and optimitized later on...
Thankx for bringing it up and clarifying it
Ragu

[Peter den Haan]

Doh. Thanks Jose - spot on.

[Caroline Bogart]

So, wait, does that mean that:
String string = "hello";
is not gc'd and
String string2 = new String("hello");
is gc'd?
Wouldn't make sense because the first is just shorthand for the second. Am I missing a point?
BTW, the Syngress Java cert book (for which I can post many hundreds of mistakes) makes a point of having the user learn when String objects are gc'd.
But I will take JavaRanch's word for it any day

Caroline

Originally posted by Ragu Sivaraman:
Yeah i did come across these issues and many times i got it wrong
when i choose "string litreal wont be gc'ed" since
the mock exams keys says "the string literal will be gc'ed" becoz they are created using new operator for the first time and optimitized later on...
Thankx for bringing it up and clarifying it
Ragu

[Peter den Haan]

Yes, Caroline, that's what it means. The second is not just a shorthand for the first. In the first, you assign a reference to the string constant "hello" to string. In the second case, you construct a new String object (which will be allocated on the heap) the contents of which are identical to that of the "hello" string constant.
Taking that knowledge as a starting point, try to predict the output of the following:

String s1 = "hello";
String s2 = "hello";
String s3 = new String("hello");
System.out.println(s1 == s2);
System.out.println(s1 == s3);
System.out.println(s1.equals(s3));

If you're sceptical, try it...
- Peter

[Wagner Danda]

Just to remember, Strings also have the intern() method:
String sA = "hello";
String sB = new String("hello");
String sC = new String("hello").intern();
System.out.println(sA == sB); // false
System.out.println(sA == sC); // true
Wagner Danda

Originally posted by Peter den Haan:
[B]Yes, Caroline, that's what it means. The second is not just a shorthand for the first. In the first, you assign a reference to the string constant "hello" to string. In the second case, you construct a new String object (which will be allocated on the heap) the contents of which are identical to that of the "hello" string constant.
Taking that knowledge as a starting point, try to predict the output of the following:

String s1 = "hello";
String s2 = "hello";
String s3 = new String("hello");
System.out.println(s1 == s2);
System.out.println(s1 == s3);
System.out.println(s1.equals(s3));

If you're sceptical, try it...
- Peter[/B]

[Ragu Sivaraman]

GC is for Heap
String lireals are in constant/litreal pool
So GC wont help there
Ragu

[Caroline Bogart]

To be clear... are all String values known at compile-time "constants"? And are they therefore in the literal pool and ineligible for GC? e.g., any string created at run time is eligible for GC after all references to that String are null?
Thanks.

Originally posted by Peter den Haan:
[B]Yes, Caroline, that's what it means. The second is not just a shorthand for the first. In the first, you assign a reference to the string constant "hello" to string. In the second case, you construct a new String object (which will be allocated on the heap) the contents of which are identical to that of the "hello" string constant.
Taking that knowledge as a starting point, try to predict the output of the following:

String s1 = "hello";
String s2 = "hello";
String s3 = new String("hello");
System.out.println(s1 == s2);
System.out.println(s1 == s3);
System.out.println(s1.equals(s3));

If you're sceptical, try it...
- Peter[/B]

[Valentin Crettaz]

Yes Caroline that's right !
Although there is a little thing to add.
String created at runtime (i.e. with the new keyword) can be interned into the private String pool by invoking intern() on the dynamically created String object. intern() returns a reference to the String in the String pool.
For instance,
String st = new String("test"); // test is not in the pool
st=st.intern(); // puts the String inside the String pool and returns a reference to it.
Now if you dereference st (st=null) the String "test" will still be in the String pool after garbage collection.
HIH

------------------
Valentin Crettaz
Sun Certified Programmer for Java 2 Platform