String Comparison and the String Pool

Comparing Strings correctly in Java requires understanding two related concepts: the String Constant Pool, a special area of memory where certain String objects are shared and reused, and the difference between comparing references (==) and comparing content (.equals()). Getting this wrong is one of the most common sources of subtle bugs for Java beginners.

Why it matters

Comparing strings with == is the classic Java bug: it appears to work in simple tests, because literals share one pooled object, and then fails with real data read from a file, a form or a database. Understanding the pool explains both why the bug hides and why equals() is always the correct comparison for text.

How the String Pool Works

When the compiler encounters a String literal, it checks the String Constant Pool first. If an identical String already exists there, the new reference simply points to that existing object instead of allocating a new one. If it does not exist yet, the literal is added to the pool. This pooling only happens automatically for literals — Strings created with new String(...) always bypass the pool and get a distinct object on the heap, even if the same text is already pooled.

== vs .equals()

== on Strings (a reference type) compares whether two variables point to the exact same object in memory, not whether their characters match. .equals(), which String overrides from Object, compares the actual character sequence. Because pooled literals with identical content share one object, == can appear to "work" for literals, which misleads many beginners into using it habitually — until a new String(...) or a runtime-built String breaks the assumption.

• Two identical literals ("cat" == "cat") are true because both point to the same pooled object.
• A literal compared to a new String(...) with the same text is false, because "new" forces a separate heap object.
• Content should always be compared with .equals() (or .equalsIgnoreCase() for case-insensitive checks), never ==.

Interning Strings Explicitly

The intern() method lets you manually add a heap-allocated String's content to the pool (or retrieve the existing pooled reference if that content is already there). Calling new String("cat").intern() returns the same reference as the literal "cat", so comparing them with == afterward would be true. Interning is occasionally useful for memory optimization when an application handles huge numbers of duplicate runtime Strings, but it should not be treated as a substitute for using .equals() in ordinary comparisons.

Example

public class StringPoolDemo {
    public static void main(String[] args) {
        String a = "cat";
        String b = "cat";
        String c = new String("cat");
        String d = c.intern();

        System.out.println("a == b: " + (a == b));           // same pooled object
        System.out.println("a == c: " + (a == c));           // c is a separate heap object
        System.out.println("a.equals(c): " + a.equals(c));   // same content
        System.out.println("a == d: " + (a == d));           // d is interned, points to pool
    }
}

a == b: true
a == c: false
a.equals(c): true
a == d: true

Exercise

The method below compares two strings with ==, so the program prints false even though both hold the text "java". Fix the comparison so it prints true, and make it safe when either argument is null.

public class SameText {

    static boolean sameText(String x, String y) {
        return x == y;
    }

    public static void main(String[] args) {
        String a = "java";
        String c = new String("java");
        System.out.println(sameText(a, c));
    }
}

import java.util.Objects;

public class SameText {

    static boolean sameText(String x, String y) {
        return Objects.equals(x, y);
    }

    public static void main(String[] args) {
        String a = "java";
        String c = new String("java");
        System.out.println(sameText(a, c)); // true
    }
}

Quick quiz

Interview questions