What Is Type Erasure in Java?

Type erasure is how the Java compiler implements generics. When it compiles a generic class or method, it erases the type parameters: it removes them from the class file and replaces every use of them with the appropriate type or bound.

For an unbounded type parameter the replacement is Object. For a bounded one, it is the bound — so T extends Number becomes Number. The compiler then inserts casts wherever the compiler needs them, which is why you never see a cast in the source but the program still works at run time.

import java.util.ArrayList;
import java.util.List;

public class Main {
    public static void main(String[] args) {
        List<String> strings = new ArrayList<>();
        List<Integer> numbers = new ArrayList<>();
        strings.add("hello");

        // At run time both are just a List.
        System.out.println("same class : " + (strings.getClass() == numbers.getClass()));
        System.out.println("class name : " + strings.getClass().getName());

        // The compiler inserted the cast for you.
        String first = strings.get(0);
        System.out.println("element    : " + first.getClass().getSimpleName());

        // You cannot ask a generic object what its type parameter was.
        System.out.println("no type argument survives at run time");
    }
}

The output shows the erasure in action. The two lists have the same runtime class, because List<String> and List<Integer> are the same type at run time. And the element still prints as a String, because the compiler inserted the cast.

Type erasure exists for compatibility. When generics were added, the enormous body of earlier code had to keep working, including code that called into libraries. Erasure means a generic class has the same class file shape as it would without generics, so old binaries and new ones interoperate. It also means the raw types you see in older code are not a separate thing — they are the erased type.

The consequences are real. You cannot overload two methods that differ only by type argument. You cannot use a primitive as a type argument without boxing. You cannot check a type parameter with instanceof. And you cannot recover the type argument from a generic object at run time, which is why frameworks that need it use reflection or explicit type tokens.

Because of type erasure. After the compiler removes the type parameters, void print(List<String>) and void print(List<Integer>) both become void print(List). That is the same signature, and the compiler rejects the class with a name-clash error: the two methods have the same erasure.

The rule is that a method signature may not be the erasure of another method signature with the same name. It applies to generics on the method as well as to generics on the parameters, which is why you cannot have <T> void m(T a) and <T, U> void m(T a) either — they erase to the same thing.

The same restriction is why you cannot have an overload that takes a List<String> and one that takes a List<Integer>, even though it would be enormously convenient. The compiler is protecting you from a class file that would be ambiguous at run time, where there would be no way to tell which one a caller meant.

import java.util.List;

public class Main {
    public static void main(String[] args) {
        List<String> strings = List.of("a", "b");
        List<Integer> numbers = List.of(1, 2);

        System.out.println("strings : " + strings);
        System.out.println("numbers : " + numbers);

        // A generic helper works for both, because there is only one of it.
        System.out.println("size of strings : " + size(strings));
        System.out.println("size of numbers : " + size(numbers));
    }

    // One generic method covers every List type.
    static <T> int size(List<T> values) {
        return values.size();
    }
}

The output shows the way out. Rather than two overloads that cannot exist, there is one generic method that handles any list, with the compiler inferring T at each call site.

Three practical workarounds when you really do want different behaviour per type. Use different method names, which is often clearer anyway. Use a single generic method with a bounded type parameter and let the compiler dispatch, though the bound cannot be a primitive. Or use wildcards in the parameter position to widen what the method accepts, which is the usual answer when the difference is about the argument type rather than the method body.