We haven't explicitly mentioned that they are "new" arrays so why doesn't they reference to the same object on the heap?
The real question here is: Why would they? It would be a real pain if, in the general case, equivalent objects were conflated by the JVM. Many classes have mutable instances; it's a bit of a problem if you have mutable instances (and arrays are mutable) and the JVM combines them into a single instance without your asking it to.
So by extension, the real question is: Why do your s1
and s2
refer to the same object?
The answer is: Because strings are a special case that the JDK and JVM have special handling for. Strings in Java were designed to be shared where possible, to save on memory size and churn, and so:
They're immutable (although you can break that via reflection if you try hard enough), and so sharing instances is acceptable (since you're not going to change them, officially).
Strings have the ability to be intern
ed, putting them in the JVM-managed string pool.
String literals are automatically intern
ed.
Your s1
and s2
wouldn't refer to the same string if it weren't for #3. Example (live copy):
String s1 = "Some string";
int a = 1;
String s2 = (a == 1 ? "Some" : "Foo") + " string";
System.out.println("Same? " + (s1 == s2));
System.out.println("Equivalent? " + s1.equals(s2));
Output:
Same? false
Equivalent? true
The string generated by the expression and assigned to s2
can't be automatically intern
ed, so it ends up referring to a diffrent string object.
If you had a class with immutable instances, you could implement intern
for them as well. Strings are only special in that it's done for us by the Java specification and runtime.