Strings in Java : equals vs ==

Question

  String s1 = "andrei";
  String s2 = "andrei";

  String s3 = s2.toString();

  System.out.println((s1==s2) + " " + (s2==s3));

Giving the following code why is the second comparison s2 == s3 true ? What is actually s2.toString() returning ? Where is actually located (s2.toString()) ?

Answer 1

First of all String.toString is a no-op:

/**
 * This object (which is already a string!) is itself returned.
 *
 * @return  the string itself.
 */
public String toString() {
    return this;
}

Second of all, String constants are interned so s1 and s2 are behind the scenes changed to be the same String instance.

Answer 2

Given that == compares references, you can see from s2 == s3 being true that s2.toString() returns s2.

Answer 3

The method String.intern() can be used to ensure that equal strings have equal references. String constants are interned, so s1 and s2 will reference the same string. String.toString() simply returns itself, that is, a.toString() returns a, when a is a String. So, s2 also == s3.

In general, strings should not be compared by reference equality, but by value equality, using equals(). The reason is that it's easy to get two strings that are equivalent but different references. For example, when creating substrings. An exception to this rule is that if you know both strings have been interned beforehand (or you intern them as part of the comparison.)

To answer your implied question about heap or stack, Strings are allocated on the heap. Even if they were allocated on the stack, such as with the upcoming escape analysis and stack allocation, the semantics of the program will not change, and you will get the same result for both heap and stack allocation.

Answer 4

You should be using .equals and not == when comparing java strings.

== Compares references and therefore s2.ToString() returns s2.

From the java glossary about heap / stack:

In Sun’s JVM, the interned Strings (which includes String literals) are

stored in a special pool of RAM called the perm gen, where the JVM also loads classes and stores natively compiled code. However, the intered Strings behave no differently than had they been stored in the ordinary object heap.

Answer 5

s2.toString () is returning a String representation. Since it's already a String it returns itself (thats why the comparison is true).

All Strings are allocated on the Heap, the coparison operator just compares whether they are the same object (thats why s1 != s2).

Answer 6

Since String are immutables, a useful implementation of the toString method is - in the String class - to return this.

As an example, my rt.jar contains the following implementation :

public String toString() {
return this;
}

As a consequence, the reference associated to s3 is the same than the one associated to s2.

Considering the s1==s2 statement, it is due to the automatic call to intern() for all constant Strings. That means that at compile time, s2 initialization code will be replaced by s2=s1, which makes the assertion quite obvious, no ?

Answer 7

From the java virtual machine spec:

String literals and, more generally, strings that are the values of constant expressions are "interned" so as to share unique instances, using the method String.intern.

"andrei" is a String literal and therefore "interned". Therefore both String s1and s2 refer to the same String object, an interned String with the content "andrei".

Therefore (s1 == s2) && (s1.equals(s2)) is true. String#toString() doesn't create a new String (like many other methods from String) but simple returns this. Therfore s2 == s3 is true.