What is type erasure in Java generics, and what happens to generic type information when code is compiled to bytecode?

## What problem generics solve Before Java 5, a `List` held `Object` references. You had to cast every element when reading it (`String s = (String) list.get(0);`), and nothing stopped you putting an `Integer` into a list meant for `String`s — the mistake only surfaced as a `ClassCastException` at runtime. **Generics** (Java 5, 2004) let you write `List<String>` so the *compiler* checks that only `String`s go in and automatically casts on the way out. This is purely a **compile-time** guarantee. ## What 'type erasure' means **Erasure** is the compiler step that, after it has finished type-checking your generic code, *removes* the generic type arguments and produces bytecode that looks almost exactly like the old pre-generics code. Concretely the compiler: 1. **Replaces each type parameter with its bound.** An unbounded `T` becomes `Object`. A bounded `T extends Number` becomes `Number` (the *leftmost* bound if there are several, e.g. `T extends Number & Comparable` → `Number`). 2. **Inserts casts** wherever a generic value is read, so the program still behaves type-safely. 3. **Generates bridge methods** — synthetic methods that preserve correct overriding/polymorphism after the type parameters are gone (e.g. so `compareTo(Object)` still routes to your `compareTo(MyType)`). So `List<String>` and `List<Integer>` both compile down to plain `List`, and there is exactly **one** runtime class: `List.class`. The angle-bracket information is not stored in the *type* of the object. ### Worked example Source: ```java List<String> list = new ArrayList<>(); list.add("hi"); String s = list.get(0); ``` After erasure the bytecode is equivalent to: ```java List list = new ArrayList(); list.add("hi"); String s = (String) list.get(0); // compiler-inserted cast ``` ## Why Java chose erasure The alternative — **reified** generics, where `List<String>` is a genuinely distinct runtime type (as in C#) — was rejected mainly for **migration/backward compatibility**. In 2004 there were billions of lines of existing pre-generics `List` code and compiled libraries. Erasure means a generified `ArrayList` produces a class file that old code can still use and that interoperates with raw types, and the JVM did not need new bytecode for parameterised types. The cost is paid at runtime: the generic information is *largely* gone. ## What erasure makes impossible Because the type argument is not part of the object's runtime type, you cannot, at runtime: - create an array of a type parameter: `new T[10]` (compile error); - get a class literal of a parameter: `T.class` (compile error); - test `obj instanceof List<String>` (only `instanceof List<?>` is allowed); - overload two methods that differ only by type argument (`m(List<String>)` and `m(List<Integer>)` have the **same erasure** → compile error). ## The important nuance (links to the rest of this topic) Erasure removes generics from the *object's runtime type*, but the compiler does **not** throw the information away entirely. For type *uses that appear in declarations* — a class's superclass, a field's type, a method's parameter and return types — the compiler records the full generic form in a class-file **`Signature` attribute**. The **reflection** API can read that attribute (`getGenericSuperclass`, `getGenericType`, `getGenericParameterTypes`) to recover the declared type arguments at runtime. So the right mental model is: *the runtime type is erased, but declared generic signatures are retained as metadata.*