How type erasure works

For this lesson, we'll focus on exactly what javac does: replacing type parameters with bounds, inserting casts at use sites, generating bridge methods, and leaving enough signature metadata for reflection. Then we'll connect that to the restrictions you see in code: no new T(), no new T[], no instanceof List<String>, no overloads that differ only by generic argument, shared static fields, no generic exceptions, heap pollution, @SafeVarargs, Class<T> tokens and super type tokens.

01Picture it first: a checked label that gets peeled off

Picture generics as a label on a shipping box. While the box is in the warehouse, the label says List<String>, and workers are not allowed to put integers in it. When the box reaches the truck, the detailed label is peeled down to List, with a few instructions left on the manifest saying where casts are needed.

That's the mental model: source code is strongly typed, bytecode is compatible. The compiler does the careful checking up front, then emits bytecode that can run beside code compiled before generics existed.

Fig. 1

A generic source class Box flows through javac into erased bytecode where T becomes Object, reads get checkcast instructions, and Comparable gets a bridge compareTo(Object) method

Notice the three compiler moves in the picture. Type parameters become bounds. Reads get casts. Bridge methods preserve polymorphism after method signatures have been erased.

02Type erasure under the hood: bounds, casts and bridges

The simplest generic class erases T to Object, because T has no explicit bound.

final class Box<T> {
    private T value;

    Box(T value) {
        this.value = value;
    }

    T get() {
        return value;
    }
}

class BoxUse {
    public static void main(String[] args) {
        Box<String> box = new Box<>("paid");
        String status = box.get();
        System.out.println(status.toUpperCase());
    }
}

Conceptually, javac emits something like this:

final class ErasedBox {
    private Object value;

    ErasedBox(Object value) {
        this.value = value;
    }

    Object get() {
        return value;
    }
}

class ErasedBoxUse {
    public static void main(String[] args) {
        ErasedBox box = new ErasedBox("paid");
        String status = (String) box.get();
        System.out.println(status.toUpperCase());
    }
}

The cast is at the use site, where the compiler knows the target type is String. That is why heap pollution often fails far away from the write that caused it: the bad value can sit inside an erased structure until a read performs the inserted cast.

Bounds change the replacement type. T extends Number erases to Number. Multiple bounds erase to the first bound, so T extends Number & Comparable<T> erases to Number while the extra interface bound stays in the generic signature metadata.

final class NumberBox<T extends Number> {
    private final T value;

    NumberBox(T value) {
        this.value = value;
    }

    double asDouble() {
        return value.doubleValue();   // allowed because erased T is Number
    }
}

Bridge methods, verified with javap

Bridge methods are the part candidates often miss because source code hides them. Suppose a class implements Comparable<Money>:

final class Money implements Comparable<Money> {
    private final long cents;

    Money(long cents) {
        this.cents = cents;
    }

    @Override
    public int compareTo(Money other) {
        return Long.compare(this.cents, other.cents);
    }
}

Comparable<T> erases its method to compareTo(Object). But our source method is compareTo(Money). To keep old callers and polymorphism working, javac generates a synthetic bridge method that accepts Object, casts it to Money, and delegates.

This is real javap -c output from compiling the class above with javac --release 21: