Type Erasure

A raw type is a generic class or interface used without its type arguments, like writing List instead of List<String>. Java allows it mainly so old pre-generics code (before Java 5) still compiles.

Type erasure means the compiler removes generic type arguments after checking them, so at runtime a List<String> is just a List. The type parameters are replaced with their bounds (usually Object), and casts are inserted automatically.

Because generic types are gone at runtime you cannot do new T[], T.class, or instanceof List<String>, and you cannot overload methods that differ only by type argument. Workarounds: pass a Class<T> token, use reflective array creation, or use a super type token.

A reifiable type is one whose full type information is still available at runtime. Because Java generics are erased (forgotten) at compile time, types like List<String> are NOT reifiable, while String, int, and List (the raw type) are.

Because the type is gone at runtime, you can't do new T(), T.class, new T[10], or check obj instanceof List<String>. You also can't overload methods that differ only by their generic argument. The common fix is to pass a Class<T> token so the type is available at runtime.

Erasure only changes the object's runtime type. The compiler still records the full generic form of declarations (superclass, fields, method params/returns) in a hidden class-file 'Signature' attribute. Reflection reads that attribute to report the original type arguments.

A raw type like plain List turns off generic checking, so you can put any object into it. If that same object is also viewed as a List<String>, you have heap pollution. Java allows the mix only so old pre-generics code still compiles.

A bridge method is an extra method the compiler adds automatically when you override a method from a generic class or interface. It exists so that overriding still works after generics are erased to raw types at compile time.

Heap pollution is when a variable typed for one kind of element (say List<String>) actually points to an object holding the wrong type. The compiler trusted you, so the error only shows up later as a ClassCastException when something reads the value.

A type parameter with a bound, like T extends Number, is replaced by that bound (Number) instead of Object. With several bounds (T extends A & B), the compiler uses the first one listed, so the order you write the bounds matters.

Because erasure turns a generic method's return type into Object (or the bound), the compiler automatically adds a cast wherever you read a generic value, like turning list.get(0) into (String) list.get(0). You don't see these casts, but they're in the bytecode and keep your code type-safe.

An unchecked warning is the compiler telling you it can't guarantee an operation is type-safe — typically because you used a raw type. The fix is to parameterize the type properly, not to ignore the warning.

You can only use instanceof with reifiable types. 'x instanceof List<String>' is a compile error because the <String> is erased and can't be checked at runtime; use 'x instanceof List<?>' or raw 'List' instead. Casts to List<String> compile but give an 'unchecked' warning.

Reflection lists bridge methods alongside real ones, so you can see two methods with the same name. You should skip bridge methods (check Method.isBridge()) so you don't process duplicates or pick the one with the wrong, erased parameter/return types.

@SafeVarargs tells the compiler 'I checked this generic varargs method, it does not misuse the array, so stop warning.' Use it only when the method just reads the varargs and never lets the array escape or get the wrong type stored in it.

Varargs are really an array under the hood. With generics you would need an array of a generic type, which Java cannot fully create safely. So the compiler warns that this array could be misused and cause type errors later.

You can assign a parameterized type (like List<String>) to a raw type (List) freely — no warning. Going the other way, raw List to List<String>, compiles but gives an unchecked warning because the compiler can't verify the element type.

If you add a wrong-typed object through a raw List, it compiles (with a warning). The crash happens later, when other code reads an element expecting a specific type — the compiler-inserted cast fails and throws ClassCastException.

You make an anonymous subclass of a generic base, like new TypeReference<List<String>>(){}. Because a subclass's superclass is a declaration, its generic argument is stored in the Signature attribute. The base reads it via getClass().getGenericSuperclass() and recovers List<String>.

Reifiable: int, String, List (raw), List<?>, String[]. Non-reifiable: List<String>, List<? extends Number>, List<String>[]. The rule: a type is reifiable if it loses nothing to erasure — primitives, non-generic types, raw types, unbounded-wildcard parameterizations, and arrays of reifiable types.

Arrays remember their element type at runtime and check every store against it. A List<String>[] can't do that check (the <String> is erased), so Java bans new List<String>[10] to keep the array's store-check honest. Workarounds: use new List<?>[], or better, use a List<List<String>>.

Erased generics (Java) drop type arguments at runtime, giving backward compatibility and one class per generic type but losing runtime type info. Reified generics (C#) keep the arguments at runtime, enabling new T[] and typeof(T), at the cost of more runtime machinery and a clean break from old code.

Covariant returns let an override return a more specific type than the parent method. The JVM can't naturally dispatch on return type, so the compiler adds a bridge method with the parent's return type that calls your override and returns its result.

Java added generics using type erasure to stay compatible with older code that had no generics, so type info is dropped at compile time. Bridge methods exist to patch up overriding after erasure. With reified generics (like C#), types are kept at runtime and no bridges are needed.

Don't rely on @SafeVarargs promises. Inside the method, immediately copy the varargs into a List and work with that, never returning or storing the raw array. Then there is nothing that can be polluted.

Java used erasure so that new generic code could work with old pre-Java-5 libraries and run on the unchanged JVM, with no extra classes generated. The cost is losing the type at runtime, unlike C#, which kept full type info (reified generics).

Almost never in new code. The legitimate cases are narrow: using class literals (List.class) and the instanceof operator, where you must use the raw form. Otherwise prefer List<String> or the wildcard List<?>.

Java chose erasure mainly for backward compatibility: generic code had to run on the existing JVM and interoperate with pre-generics libraries without rewriting them. The cost is that type info is lost at runtime, causing the reifiability restrictions (no new T[], limited instanceof). C# reified generics, keeping runtime type info, at the price of breaking with its earlier model.