Which string expressions get pooled at compile time, and why does "a"+"b" == "ab" but s+"b" (with s a variable) does not?

## The mechanism: constant folding The Java compiler (`javac`) evaluates **compile-time constant expressions** at compile time and replaces them with their result. For strings, a constant expression made of literals and constant operands collapses into a single string **literal** that is placed in the class file's constant pool and therefore **interned**. A **compile-time constant** (per the JLS) is: - a string literal (`"a"`), - a `final` variable initialized with a constant expression (`final String X = "a";`), - and combinations of these with `+`. ## Case A: all constants -> pooled ```java String ab = "ab"; String joined = "a" + "b"; // folded by javac to the literal "ab" ab == joined; // true — same pooled object ``` Because `"a" + "b"` is fully constant, `javac` computes `"ab"` and emits it as a single literal; both names reference the one pooled instance. ## Case B: a variable operand -> runtime, not pooled ```java String s = "a"; String joined = s + "b"; // s is a (non-final) variable -> runtime concat "ab" == joined; // false — joined is a fresh heap object ``` Here `s` is **not** a compile-time constant, so the concatenation cannot be folded. The compiler emits code that builds the string at runtime. Historically this used a `StringBuilder`; since Java 9 it uses an `invokedynamic` call to `StringConcatFactory`. Either way the produced `String` is **brand new** and **not** in the pool, so `==` against the pooled `"ab"` is `false` (though `.equals()` is `true`). ## Case C: final variable -> counts as constant ```java final String s = "a"; // final + constant initializer => compile-time constant String joined = s + "b"; // folded to "ab" "ab" == joined; // true ``` Making `s` `final` with a constant initializer turns it back into a compile-time constant, so folding applies again and the result is pooled. ## Case D: non-final or computed -> not constant ```java String s = getValue(); // method call -> not constant, even if final final String s2 = getValue();// final but initializer not constant -> not compile-time constant ``` A `final` whose initializer is itself not a constant (e.g. a method result) is **not** a compile-time constant, so no folding. ## Forcing pooling at runtime When folding does not apply, use `intern()`: ```java String s = "a"; ("ab".equals((s + "b").intern())); // intern() returns the pooled "ab" "ab" == (s + "b").intern(); // true ``` ## Why it matters 1. **`==` on strings is fragile.** Whether two equal-valued strings are `==` depends on subtle folding rules that are easy to break (change `final`, introduce a variable, refactor a concat). Use `.equals()`. 2. **Performance/memory understanding.** Knowing that runtime concatenation allocates explains hidden object churn in loops. 3. **Interview signal.** Predicting these `==` results correctly demonstrates real understanding of the pool, folding, and immutability. ## Summary | Expression | Folded? | `== "ab"` | |---|---|---| | `"a" + "b"` | yes | true | | `s + "b"` (non-final var) | no | false | | `final s="a"; s + "b"` | yes | true | | `(s + "b").intern()` | n/a (runtime+intern) | true |