This week's book giveaway is in the Big Data forum.
We're giving away four copies of Elasticsearch in Action and have Radu Gheorghe & Matthew Lee Hinman on-line!
See this thread for details.
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes == with Strings is giving a different result Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Elasticsearch in Action this week in the Big Data forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "== with Strings is giving a different result" Watch "== with Strings is giving a different result" New topic

== with Strings is giving a different result

Mo Bustany

Joined: Feb 03, 2003
Posts: 11
Given the following

Why isn't s1 identical to s4 but s2 is identical to s1!!!
Veena Pointi
Ranch Hand

Joined: Jun 20, 2002
Posts: 442
Coz == operator compares object references(memory addresses which is bit representaion),but equlas() method compares objects .Coz equals() method is overriden in String class.
s1,s2,s3,s4 all are different objects reffering to different memory locations on the heap .So if you compare any of the above 2 objects using == ,it returns false.

"Continuous effort - not strength or intelligence - is the key to unlocking our potential."
*Winston Churchill
Varun Khanna
Ranch Hand

Joined: May 30, 2002
Posts: 1400
The behaviour of equals() function is fine.
Regarding == comparison, the string s1 and s2 are pointing to same object in the compiler's pool whereas s4(=s3 + "c")is an object on heap and hence is not pointing to the "abc" object present in the pool.Hence, s1 and s2 are same whereas s4 is pointing to different location.
You can also try to add a String s5 = s1; and comparing s1 == s5 is returning true.As both are pointing to object in compiler's pool.
Further, to verify this try to add this line of code ---->
if (s1 == s4.intern())
This returns true, as calling intern method, returns the string form of s4 object from the pool.
Hope this helps.
[ June 25, 2003: Message edited by: varun Khanna ]

- Varun
Anupam Sinha
Ranch Hand

Joined: Apr 13, 2003
Posts: 1090
Hi Mo
It's so because s1 and s2 refer to the same thing because "abc" and "ab" + "c" are both compile time constants. So the value is calculated at compile time. But the value of s3 + "c" is calculated at runtime and hence s3 + "c" is not in the pool. That is s3 + "c" is a freshly made string and hasn't been interned so a new memory location is assigned to it. Though both the Strings are identical except the fact that their memory locations are different.
[ June 25, 2003: Message edited by: Anupam Sinha ]
Marlene Miller
Ranch Hand

Joined: Mar 05, 2003
Posts: 1391
Here is what the compiler does for �ab� + �c�;
s2 = �abc�; //store a reference to String object in this variable.
The concatenation of two compile-time String constants is a compile-time String constant.
Here is what the compiler does for s3 + �c�:
StringBuffer sb = new StringBuffer();
s4 = sb.toString(); //create a new String object
The concatenation of a String variable and a compile-time String constant is a run-time computation to create a new String object.
Marlene Miller
Ranch Hand

Joined: Mar 05, 2003
Posts: 1391
Even if you are not familiar with byte-codes, it can be somewhat convincing to see what the compiler is doing.
I agree. Here's the link:
subject: == with Strings is giving a different result