Why is that a concatenation using "+" operator of a Java reference variable and a literal does not result in String interning?

Question

Consider following snippet.

CASE #1

public class HelloWorld {
    public static void main(String[] args) {
        String str1 = "abc";
        String str2 = "ab";

        str2 = str2 + "c";

        System.out.println("str1 :" + str1+ ", str2 :" + str2);

        System.out.println(str1 == str2);
    }
}

The result is

 sh-4.3$ java -Xmx128M -Xms16M HelloWorld                                                                                                                                        
 str1 :abc, str2 :abc                                                                                                                                                            
 false

Here, the result of str1 == str2 comes out to be false. However, if you use "+" operator to concatenate two literals. It gives you the address of the string literal "abc" from string constant pool. Consider following snippet

CASE #2

public class HelloWorld {
    public static void main(String[] args) {
        String str1 = "abc";
        //String str2 = "ab";

        str2 = "ab" + "c";

        System.out.println("str1 :" + str1 + ", str2 :" + str2);

        System.out.println(str1 == str2);
    }
}

The result is

  sh-4.3$ java -Xmx128M -Xms16M HelloWorld                                                                                                                                        
  str1 :abc, str2 :abc                                                                                                                                                            
  true 

Can someone please explain why string interning is done in CASE #2 and not in CASE #1? Why do we get 'str1==str2' as false in CASE #1 and true in CASE #2?

Answer 1

Because the JLS #3.10.5 specifies compile-time interning of string literals or constant string expressions, and doesn't specify any interning in the case of non-constant string expressions.

Also specified in JLS #15.28.

Answer 2

You'll notice because of the Final, the compiler considers this a constant expression and interns it in this case as well.

public class HelloWorld {
  public static void main(String []args) {
    String str1 = "abc";
    final String str2 = "ab";

    String str3 = str2 + "c";

    System.out.println("str1 :" +str1+", str3 :"+str3);

    System.out.println(str1 == str3);
  }
}

Answer 3

The crucial factor isn't that it's a string literal, it's that it's a constant expression. This is defined in JLS 15.28, which lists all of the ways you can have a constant expression. That list includes "literals of type String" and concatenations of two String constants*, but not of non-final variables, even if those variables happen to be set and never changed.

JLS 15.28 is also what specifies that "Constant expressions of type String are always 'interned'", so if something is not a constant expression -- for instance, if it includes non-final variables -- then it won't be interned.

---

_{* This is expressed slightly awkwardly, but basically 15.28 says that an expression is constant if it only consists of a bunch of things, and one of those things is the additive operator +, which for Strings performs concatenation -- there's not actually a separate "concatenationi operator."}

Answer 4

Several of the existing answers here already cover, in a strict sense, why the interning doesn't happen: it isn't required by the JLS.

The JLS specicies both that interning must happen in the "literal" + "literal" case (per 15.18.1, and also that non-constant expressions must be newly created (also in 15.18.1). The relevant section on newly created objects seems to leave open the possibility of the compiler or runtime interning the non-literal case as well (quotation marks added):

Execution of a string concatenation operator (§15.18.1) that is not part
of a constant expression (§15.28) "sometimes" creates a new String object
to represent the result. String concatenation operators may also create
temporary wrapper objects for a value of a primitive type. 

Here, I believe the "sometimes" creates part refers to the fact that the compiler (or runtime) can optmize away a series of concatentation operations within a single expression, such as foo + 1 + anotherFoo + bar() to newly create only a single string for the final result - but it does not allow a compiler or runtime to intern the final result.

One practical reason it would not be a good idea to intern all strings is that interning is a relatively expensive, global operation. Interned strings must be recorded, checked for uniqueness, and all that must be safe across threads which may involve a lock or some faster but still slow lock-free logic. In fact, in large applications, String.intern() can be a significant contention point if the size of the default intern table is not increased (it seems locking occurs per-bucket in the table).

Once the requirement was written in this way, it's essentially impossible for future specifications to loosen it, since existing code may easy depend on objects being newly created: the distinction is readily evident not only via operator == but also when locking an object, using identity hash codes, etc.

For a counterpoint, consider the behavior of autoboxed integers, as well as the related static methods such as Integer.valueOf():

This method will always cache values in the range -128 to 127,
inclusive, and may cache other values outside of this range.

The caching mentioned here is essentially equivalent to interning. In this case, the JLS left open the possibility of interning integers outside the range -128 to 127 - i.e., left it up to the implementation. Indeed, this makes the use of valueOf less predicable for the developer, but gives more flexibility to the implementation, and this flexibility was in fact used in JDK 7 to increase the size of the cached integer range - and even to make it configurable by the end user who launches the JVM.