Java == for String objects ceased to work?

  public class Comparison {
        public static void main(String[] args) {
            String s = "prova";
            String s2 = "prova";
            System.out.println(s == s2);
            System.out.println(s.equals(s2));
        }
    }

outputs:

true
true

on my m开发者_C百科achine. Why? Shouldn't be == compare object references equality?

Because String instances are immutable, the Java language is able to make some optimizations whereby String literals (or more generally, String whose values are compile time constants) are interned and actually refer to the same (i.e. ==) object.

JLS 3.10.5 String Literals

Each string literal is a reference to an instance of class String. String objects have a constant value. String literals-or, more generally, strings that are the values of constant expressions -are "interned" so as to share unique instances, using the method String.intern.

This is why you get the following:

System.out.println("yes" == "yes"); // true
System.out.println(99 + "bottles" == "99bottles"); // true
System.out.println("7" + "11" == "" + '7' + '1' + (char) (50-1)); // true
System.out.println("trueLove" == (true + "Love")); // true
System.out.println("MGD64" == "MGD" + Long.SIZE);

That said it needs to be said that you should NOT rely on == for String comparison in general, and should use equals for non-null instanceof String. In particular, do not be tempted to intern() all your String just so you can use == without knowing how string interning works.

Related questions

• Java String.equals versus ==
• difference between string object and string literal
• what is the advantage of string object as compared to string literal
• Is it good practice to use java.lang.String.intern()?

On new String(...)

If for some peculiar reason you need to create two String objects (which are thus not == by definition), and yet be equals, then you can, among other things, use this constructor:

public String(String original) : Initializes a newly created String object so that it represents the same sequence of characters as the argument; in other words, the newly created string is a copy of the argument string. Unless an explicit copy of original is needed, use of this constructor is unnecessary since Strings are immutable.

Thus, you can have:

System.out.println("x" == new String("x")); // false

The new operator always create a new object, thus the above is guaranteed to print false. That said, this is not generally something that you actually need to do. Whenever possible, you should just use string literals instead of explicitly creating a new String for it.

Related questions

• Java Strings: “String s = new String(”silly“);”
• What is the purpose of the expression “new String(…)” in Java?

JLS, 3.10.5 => It is guaranteed that a literal string object will be reused by any other code running in the same virtual machine that happens to contain the same string literal

If you explicitly create new objects, == returns false:

String s1 = new String("prova");
String s2 = new String("prova");
System.out.println(s1 == s2); // returns false.

Otherwise the JVM can use the same object, hence s1 == s2 will return true.

It does. But String literals are pooled, so "prova" returns the same instance.

String s = "prova";
String s2 = "prova";

s and s2 are literal strings which are pointing the same object in String Pool of JVM, so that the comparison returns true.

Yes, "prova" is stored in the java inner string pool, so its the same reference.

Source code literals are part of a constant pool, so if the same literal appears multiple times, it will be the same object at runtime.

The JVM may optimize the String usage so that there is only one instance of the "equal" String in memory. In this case also the == operator will return true. But don't count on it, though.

You must understand that "==" compares references and "equals" compares values. Both s and s1 are pointing to the same string literal, so their references are the same.

When you put a literal string in java code, the string is automatically interned by the compiler, that is one static global instance of it is created. Or more specifically, it is put into a table of interned strings. Any other quoted string that is exactly the same, content-wise, will reference the same interned string.

So in your code s and s2 are the same string

Ideally it should not happen ever. Because java specification guarantees this. So I think it may be the bug in JVM, you should report to the sun microsystems.