"==" in case of String concatenation in Java
Solution 1:
Four things are going on:
(You clearly know this, but for lurkers)
==
tests to see if the variables point to the sameString
object, not equivalent strings. So even ifx
is"foo"
andy
is also"foo"
,x == y
may be true or false, depending on whetherx
andy
refer to the sameString
object or different ones. That's why we useequals
, 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. :-)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.-
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 newString
object for the new constant is added to the pool). So even ifx
is a string constant initialized in classFoo
andy
is a string constant initialized in classBar
, 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.)
-
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., noStringBuilder
is used, the concatenation happens at compile-time, not runtime. This is covered in JLS§15.28 - Constant Expressions. Soa == d
is true for the same reasona == 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 thuse
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 theStringBuilder
code you referred to and that work is done at runtime, creating a newString
object. That string isn't automatically interned, soe
ends up referring to a differentString
object thana
does, and soa == e
is false.Note that as Vinod said, if you declared
c
asfinal
: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.
Solution 2:
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.