Does Declaring Strings as `final` in Java Change How `==` Compares Them?

Comparing Strings with == When Declared Final in Java

In Java, the == operator compares the memory references of two objects. However, when strings are declared as final and initialized with compile-time constants, a unique behavior arises.

Scenario 1: Non-Final Strings

Consider the following code segment:

String str1 = "str";
String str2 = "ing";
String concat = str1 + str2;

System.out.println(concat == "string");

The result of this code would be false. The concatenation operation creates a new String object, which is not equal to the pre-existing string literal "string".

Scenario 2: Final Strings

Now, let's declare the strings as final:

final String str1 = "str";
final String str2 = "ing";
String concat = str1 + str2;

System.out.println(concat == "string");

Surprisingly, the result is now true. This is because declaring the strings as final allows the compiler to inline their values and treat the entire expression as a compile-time constant expression.

Compiler Optimization: Interning

When a compile-time constant expression involves a String, the Java virtual machine (JVM) "interns" it, which means it stores a unique instance of the String in a special location called the String pool. Thus, the concatenated string in the second scenario is directly compared to the interned string "string", resulting in a true result.

Conclusion

Declaring strings as final with compile-time constants leads to the optimizer treating the expression as a single String object, allowing syntactic equality checks (==) with pre-existing string literals. This demonstrates the compiler optimization in Java and how it can impact object identity comparisons.

The above is the detailed content of Does Declaring Strings as `final` in Java Change How `==` Compares Them?. For more information, please follow other related articles on the PHP Chinese website!