"==" in case of String concatenation in Java

String a = "devender";
String b = "devender";
String c = "dev";
String d = "dev" + "ender";
String e = c + "ender";

System.out.println(a == b);     //case 1: o/p true

System.out.println(a == d);     //case 2: o/p true

System.out.println(a == e);     //case 3: o/p false

a & b both are pointing to the same String Literal in string constant pool. So true in case 1

String d = "dev" + "ender";

should be internally using something like:

String d = new StringBuilder().append("dev").append("ender").toString();

How a & d are pointing to the same reference & not a & e ?

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.

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.

"dev" + "ender" is a compile-time evaluable constant expression: both arguments are string literals. The expression is therefore "devender".

The same cannot be said for c + "ender": certain circumstances (some code running on a different thread for example) could lead to c being set to a different value. Qualifying c as final obviates this possibility, and in that case e would also refer to the same object as a.

So a, b, and d all refer to the same object.

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 ==.

String d = "dev" + "ender"; constant + constant, ‘d’ is still a constant(the same one), so (a == d) is true;

String e = c + "ender"; variable + constant, the result 'e' is a variable, it will use StringBuilder internally,and create a new reference.

Keep in mind that Java holds a pool of all string literals found in program, used for matching purposes among others, so any different string literal concatenation above will lead to the same object, to the same string literal. You can check out this useful article for more.

On the other hand, the concatenation of a String object and a literal (case c + "ender") will lead to the creation of a as StringBuilder object at runtime, different to the literals found in pool.