"==" in case of String concatenation in Java

The difference between d and e is that when you concatenate string literals, the concatenation is performed at compile time. Java compiler treats "dev" + "ender" expression in the same way as "devender" expression, producing the same literal at compile time. Since all String literals get interned, d, which is a result of "dev" + "ender", also ends up referencing the same object as a and b's "devender".

The expression for e, which is c + "ender", is evaluated at runtime. Even though it produces the same string, this fact is not used by the compiler. That's why a different String object is produced, resulting in failed comparison on ==.

As you said internally the last concatenation is done to something similar to

String e = new StringBuilder().append(c).append("ender").toString();

the implementation of toString() of StringBuilder creates a new String. Here is the implementation.

public String toString() {
     // Create a copy, don't share the array
     return new String(value, 0, count);
}

Comparing strings using == instead of .equals() returns true only if both strings are the same. In this case they are not the same because the second string is created as a new object of type String.

The other concatenations are performed directly by the compiler so no new String is created.

Four things are going on:

1. (You clearly know this, but for lurkers) == tests to see if the variables point to the same String object, not equivalent strings. So even if x is "foo" and y is also "foo", x == y may be true or false, depending on whether x and y refer to the same String object or different ones. That's why we use equals, not ==, to compare strings for equivalence. All of the following is just meant to explain why == is sometimes true, it's not a suggestion to use == to compare strings. :-)

2. Equivalent string constants (strings the compiler knows are constants according to various rules in the JLS) within the same class are made to refer to the same string by the compiler (which also lists them in the class's "constant pool"). That's why a == b is true.

3. When the class is loaded, each of its string constants is automatically interned — the JVM's string pool is checked for an equivalent string and if one is found, that String object is used (if not, the new String object for the new constant is added to the pool). So even if x is a string constant initialized in class Foo and y is a string constant initialized in class Bar, they'll be == each other.

   Points 2 and 3 above are covered in part by JLS§3.10.5. (The bit about the class constant pool is a bit of an implementation detail, hence the link to the JVM spec earlier; the JLS just speaks of interning.)

4. The compiler does string concatenation if it's dealing with constant values, so

   String d = "dev" + "ender";
   

   is compiled to

   String d = "devender";
   

   and "devender" is a string constant the compiler and JVM apply points 2 and 3 above to. E.g., no StringBuilder is used, the concatenation happens at compile-time, not runtime. This is covered in JLS§15.28 - Constant Expressions. So a == d is true for the same reason a == b is true: They refer to the same constant string, so the compiler ensured they were referring to the same string in the class's constant pool.

   The compiler can't do that when any of the operands is not a constant, so it can't do that with:

   String e = c + "ender";
   

   ...even though code analysis could easily show that the value of c will definitely be "dev" and thus e will definitely be "devender". The specification only has the compiler do the concatenation with constant values, specifically. So since the compiler can't do it, it outputs the StringBuilder code you referred to and that work is done at runtime, creating a new String object. That string isn't automatically interned, so e ends up referring to a different String object than a does, and so a == e is false.

   Note that as Vinod said, if you declared c as final:

   final String c = "dev";
   

   Then it would be a constant variable (yes, they're really called that) and so §15.28 would apply and the compiler would turn

   String e = c + "ender";
   

   into

   String e = "devender";
   

   and a == e would also be true.

Just to reiterate: None of which means we should use == to compare strings for equivalence. :-) That's what equals is for.

The compiler does a lot of optimisation under the hood.

String d = "dev" + "ender";

Here the compiler will replace "dev" + "ender" with "devender" when the program is being compiled. If you are adding 2 literals (this applies to both primitives as well as Strings), the compiler does this optimisation.

Java code :

String d = "dev" + "ender";

Byte code :

  0: ldc           #16                 // String devender

Coming to a special case :

final String c = "dev"; // mark this as final
String e = c + "ender";

Making c final will make the String a compile-time-constant. The compiler will realize that the value of c cannot change and hence will replace all occurances of c with the value "dev" when compiling, thus e will be resolved during compile time itself.