== operator with Strings

Question

The code below should not print "Bye", since == operator is used to compare references, but oddly enough, "Bye" is still printed. Why does this happen? I'm using Netbeans 6.9.1 as the IDE.

public class Test {
    public static void main(String [] args) {
        String test ="Hi";
        if(test=="Hi"){
            System.out.println("Bye");
        }
    }
}

score 43 · Accepted Answer · edited Jun 20 '20 at 09:12

This behavior is because of interning. The behavior is described in the docs for String#intern (including why it's showing up in your code even though you never call String#intern):

A pool of strings, initially empty, is maintained privately by the class String.

When the intern method is invoked, if the pool already contains a string equal to this String object as determined by the equals(Object) method, then the string from the pool is returned. Otherwise, this String object is added to the pool and a reference to this String object is returned.

It follows that for any two strings s and t, s.intern() == t.intern() is true if and only if s.equals(t) is true.

All literal strings and string-valued constant expressions are interned. String literals are defined in §3.10.5 of the Java Language Specification.

So for example:

public class Test {

    private String s1 = "Hi";

    public static void main(String [] args) {

        new Test().test();
        System.exit(0);
    }

    public void test() {
        String s2 ="Hi";
        String s3;

        System.out.println("[statics]          s2 == s1? " + (s2 == s1));
        s3 = "H" + part2();
        System.out.println("[before interning] s3 == s1? " + (s3 == s1));
        s3 = s3.intern();
        System.out.println("[after interning]  s3 == s1? " + (s3 == s1));
        System.exit(0);
    }

    protected String part2() {
        return "i";
    }
}

Output:

[statics]          s2 == s1? true
[before interning] s3 == s1? false
[after interning]  s3 == s1? true

Walking through that:

The literal assigned to s1 is automatically interned, so s1 ends up referring to a string in the pool.
The literal assigned to s2 is also auto-interned, and so s2 ends up pointing to the same instance s1 points to. This is fine even though the two bits of code may be completely unknown to each other, because Java's String instances are immutable. You can't change them. You can use methods like toLowerCase to get back a new string with changes, but the original you called toLowerCase (etc.) on remains unchanged. So they can safely be shared amongst unrelated code.
We create a new String instance via a runtime operation. Even though the new instance has the same sequence of characters as the interned one, it's a separate instance. The runtime doesn't intern dynamically-created strings automatically, because there's a cost involved: The work of finding the string in the pool. (Whereas when compiling, the compiler can take that cost onto itself.) So now we have two instances, the one s1 and s2 point to, and the one s3 points to. So the code shows that s3 != s1.
Then we explicitly intern s3. Perhaps it's a large string we're planning to hold onto for a long time, and we think it's likely that it's going to be duplicated in other places. So we accept the work of interning it in return for the potential memory savings. Since interning by definition means we may get back a new reference, we assign the result back to s3.
And we can see that indeed, s3 now points to the same instance s1 and s2 point to.

@Crowder also, does that mean that the explanation in this link is wrong? http://www.gtothesquare.com/2010/04/19/java-vs-equals/ — OckhamsRazor, Jul 05 '11 at 08:36
@Ockhams: Glad that helped. Yes, the example in that link is wrong (had the author simply tried it, he/she would have known that), but only because the example uses literals and literals (and other constant string expressions) are automatically interned. The overall point of that post, that strings are objects and so if you want to compare them to see if they have the same characters you use `equals` rather than `==`, is correct. But certainly the example is just plain wrong. — T.J. Crowder, Jul 05 '11 at 08:49

score 10 · Answer 2 · edited Jul 05 '11 at 08:00

10

Hard-coded Strings are compiled into the JVM's String Table, which holds unique Strings - that is the compiler stores only one copy of "Hi", so you are comparing that same object, so == works.

If you actually create a new String using the constructor, like new String("Hi"), you will get a different object.

edited Jul 05 '11 at 08:00

Bart Kiers

166,582
36
299
288

answered Jul 05 '11 at 07:55

Bohemian

412,405
93
575
722

fyr · Answer 3 · 2011-07-05T08:11:27.153

1

There is a String cache in java. Where as in this case the same object is returned from the cache which hold the same reference.

edited Jul 05 '11 at 08:11

answered Jul 05 '11 at 07:54

fyr

20,227
7
37
53

score 0 · Answer 4 · answered Jul 05 '11 at 07:55

0

The main reason for that is because the "Hi" is picked up from String Pool. The immutable object must have some sort of cache so it can perform better. So String class is immutable and it uses String Pool for basic cache.

In this case, "Hi" is in the String pool and all the String having values of "Hi" will have the same reference for String Pool.

answered Jul 05 '11 at 07:55

Talha Ahmed Khan

15,043
10
42
49

3

Not always true. String constructor will always create a new String object. – Daniel Canas Jul 05 '11 at 07:56
`new String("Hi")` will be created on Heap and that will be whole new case. which is not discussed here. I Just explained that why == worked here. Thanks – Talha Ahmed Khan Jul 05 '11 at 07:58

== operator with Strings

4 Answers4

Linked