String Literal vs new String() in Java

Direct Answer

String s = "hello" uses the canonical interned literal. new String("hello") evaluates that literal and then creates a distinct String object with the same content; the new object is not automatically interned. Therefore equals() is true between them but == is false. The constructor is almost never needed for an existing String.

Code Example

public class LiteralVsNew {
    public static void main(String[] args) {

        String s1 = "hello";           // goes to pool
        String s2 = "hello";           // reuses pooled "hello"
        String s3 = new String("hello"); // creates new heap object, skips pool

        // Identity comparison (are they the same object?)
        System.out.println(s1 == s2); // true  — both point to pooled object
        System.out.println(s1 == s3); // false — s3 is a different object

        // Content comparison (do they have the same characters?)
        System.out.println(s1.equals(s2)); // true
        System.out.println(s1.equals(s3)); // true — same text, different object

        // Lesson: always use .equals() for content comparison
        // == is for checking if two variables point to the exact same object
    }
}

Common Mistakes & Pitfalls

• Expecting == to be true for a literal and a new String — they hold the same characters but are different objects, so == is false; this is the single most common String bug for freshers.
• Reaching for new String("...") to 'make a copy' — it copies pointlessly; literals are already safe to share because String is immutable, so the copy buys you nothing but wasted memory.
• Assuming strings from input, files, or concatenation are pooled — only literals and explicitly intern()-ed strings live in the pool; a value read at runtime is a fresh heap object, so == against a literal fails.
• Thinking .equals() and == are interchangeable — .equals() compares characters and is what you almost always want; == compares object identity and happens to work for literals by accident.