String and String Object Problem

[Gari Jain]

public class TestString
{
public static void main(String args[])
{
String s1=new String("abc");
String s2=new String("xyz");
String s3=s1+s2;
String s4="abcxyz";
String s5="abc"+"xyz";

System.out.println(s1==s2);
System.out.println(s2==s3);
System.out.println(s3==s4);
System.out.println(s4==s5);
System.out.println(s2==s4);
System.out.println(s2==s5);
System.out.println(s3==s1);
System.out.println(s3==s5);
}
}

When I run this
OUTPUT:
F
F
F
T
F
F
F
F

Please Explain Why s3 is not == s4 and s3 is not == s5

[sumit kothalikar]

just check how many String objects are created

[Abimaran Kugathasan]

Gari Jain wrote:

public class TestString
{
public static void main(String args[])
{
String s1=new String("abc");
String s2=new String("xyz");
String s3=s1+s2;
String s4="abcxyz";
String s5="abc"+"xyz";

System.out.println(s1==s2);
System.out.println(s2==s3);
System.out.println(s3==s4);
System.out.println(s4==s5);
System.out.println(s2==s4);
System.out.println(s2==s5);
System.out.println(s3==s1);
System.out.println(s3==s5);
}
}

Please Explain Why s3 is not == s4 and s3 is not == s5

Because, s1 and s2 are in the heap, not in the String literal pool, and the object, you've created as s3 is also in the heap. And s4 and s5 are in the String literal pool (One object "abcxyz", two references, s4 and s5).

[Rahul S Mishra]

Gari Jain wrote:Please Explain Why s3 is not == s4 and s3 is not == s5

Abimaran Kugathasan wrote:Because, s1 and s2 are in the heap, not in the String literal pool, and the object, you've created as s3 is also in the heap. And s4 and s5 are in the String literal pool (One object "abcxyz", two references, s4 and s5).

Surely all strings are still allocated on the heap? See Javaranch Also as per SCJP guide (Kathy & Bert),

When the compiler encounters a String literal, it checks the pool to sec if an identical String already exists. If a match is found, the reference to the new literal is directed to the existing String, and no new String literal object is created.

"String literal pool" is the key here. s4 & s5 contain reference to same object ("abcxyz" string literal is in the pool). And == looks at the bit pattern (in this case) and bit battern of s4 & s5 is same. s3 is not part of the pool and contains reference to different string object, so bit pattern is different than s4 & s5 and == fails.

[Mohit G Gupta]

When the compiler encounters a String literal, it checks the pool to sec if an identical String already exists. If a match is found, the reference to the new literal is directed to the existing String, and no new String literal object is created.

"String literal pool" is the key here. s4 & s5 contain reference to same object ("abcxyz" string literal is in the pool). And == looks at the bit pattern (in this case) and bit battern of s4 & s5 is same. s3 is not part of the pool and contains reference to different string object, so bit pattern is different than s4 & s5 and == fail

why s3 is not part of the pool ?
once

s3=s1+s2;

is executed,i think s3 will refer to a object "abcxyz"
then we

String s4="abcxyz";  //would also refer to same object as created in the above statement
String s5="abc"+"xyz";//same for this

[Abimaran Kugathasan]

mohitkumar gupta wrote:

why s3 is not part of the pool ?
once

s3=s1+s2;

is executed,i think s3 will refer to a object "abcxyz"

Since, the s1 and s2 are in the heap, the object s3 is also in the heap. Read more about String Literal pool in this link.

[Mohit G Gupta]

i read the link Abimaran refered

when you
come to the keyword "new," the JVM is obliged to create a new String object at run-time, rather than using the
one from the constant table.


the String object
referenced from the String Literal Pool is created when the class is loaded while the other String object is created
at runtime, when the "new String..." line is executed

so s3 would be assigned the value at runtime rather than at compile time
am i right ?

but ,s3 is not created using the new keyword,so it would have reference in string literal pool

as the link says:
the JVM goes through the code for
the class and looks for String literals. When it finds one, it checks to see if an equivalent String is already
referenced from the heap. If not, it creates a String instance on the heap and stores a reference to that object in
the constant table. Once a reference is made to that String object, any references to that String literal throughout
your program are simply replaced with the reference to the object referenced from the String Literal Pool

so,after line-7 there would be only one entry in the String Literal Pool, which would refer to a
String object that contained the word "abcxyz". Both of the local variables, s5 and s4, would be
assigned a reference to that single String object.

[Abimaran Kugathasan]

mohitkumar gupta wrote:

so s3 would be assigned the value at runtime rather than at compile time
am i right ?

Correct, I think!

[Vinoth Kumar Kannan]

s3 = s1 + s2;

would store a newly created string(result of s1 + s2) in the Object heap and return the reference to s3. Though values of s1 & s2 are known at compile time, s3 would be constructed at run-time!

mohitkumar gupta wrote:so s3 would be assigned the value at runtime rather than at compile time
am i right ?

Mohit, you are absolutely correct - this happens at run-time. Other than String literals, every other thing is supposed to be considered as run-time created Strings.

Abimaran Kugathasan wrote:Since, the s1 and s2 are in the heap, the object s3 is also in the heap.

Not exactly. Run time Strings will never refer to the String pool, unless otherwise you use .intern() on them. So, s3 wont be == s4 or s5.

[Abimaran Kugathasan]

Thanks Vinoth Kumar Kannan for correcting it!

[Gari Jain]

The link helped:

Abimaran Kugathasan wrote:

mohitkumar gupta wrote:

why s3 is not part of the pool ?
once

s3=s1+s2;

is executed,i think s3 will refer to a object "abcxyz"

Since, the s1 and s2 are in the heap, the object s3 is also in the heap. Read more about String Literal pool in this link.

ThankYou ALL for replying