Das's doch nur wieder die halbe Wahrheit (nämlich nur der erste Teil), darum geht's ja in diesem Thread. Die Frage ist doch, warum man das eine dem anderen vorziehen soll.
Natürlich erzeugt "new" immer ein Objekt aber das kannst du von mir aus auch "n" mal machen, sowohl erneut auf das Literal als auch auf seine Kinder und Kindeskinder. Auf diese Art erzeugte Stringobjekte verhunzen in diesem Fall immer 16 Bytes des wertvollen Heaps. Literale (Text in den Ganterpranken) werden nicht durch "new" erzeugt, sondern durch die JVM, welche den Text (das Chararray) aus dem Constantpool der Klasse bezieht. Durch [c]"new String("literal")[/c] wird die JVM höchstens daran gehindert, die Erzeugerklasse aus dem Speicher zu "entsorgen", wenn sie nicht mehr benötigt wird. Literale kopiert man anders. [c]new StringBuilder("literal").toString()[/c] forciert die oben genannte deepCopy. Die 16 + 2*n Bytes auf dem Heap finden ihre Berechtigung nun darin, ein Literal ausserhalb seiner Erzeugerklasse zu verwenden. So werden evtl. nur Stringlänge + 16 Bytes statt X-Bytes gesamte KlassenDefinition erhalten, aber auch bei diesem Konstrukt gibt's Haken, der Speicherverbrauch bei falscher Anwendung. Dieser String-Copy-Konstruktor aber ist nutzlos, solange die DeepCopy nicht erfolgt (muss ja automatisch erfolgen), was sie bei Literalen halt nicht tut, wohl aber unter Umständen bei Variablen des Typs String.