[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6},"actionData","errors","routes/blog-tag",{"_7":8,"_9":10},"tag",{"_31":95,"_73":96,"_35":97},"articles",{"_11":12,"_13":14,"_15":16,"_17":16,"_18":19,"_20":21,"_22":23,"_24":23,"_25":16,"_26":27},"content",[30],"pageable",{"_28":21,"_29":19},"totalElements",1,"totalPages","size",10,"number",0,"first",true,"last","numberOfElements","empty",false,"page_number","page_size",{"_31":32,"_33":34,"_35":36,"_37":38,"_11":39,"_40":-5,"_41":23,"_42":27,"_43":44,"_45":46,"_47":48,"_49":50,"_51":52,"_53":52,"_54":55,"_56":57,"_58":59,"_60":52,"_61":62,"_63":64,"_65":66,"_67":68,"_69":70,"_71":72},"id",98,"title","Generics Mastery","slug","java-collections-part-2-generics-mastery","excerpt","Master Java generics for collections: type erasure, wildcards (extends vs super), the PECS principle, and common pitfalls like raw types and heap pollution.","# Java Collections Part 2: Generics Mastery for Collections\n\nGenerics are the type-safety mechanism that makes Java Collections usable without constant casting. But generics in Java are more complex than they appear - understanding type erasure, wildcards, and bounded types separates developers who can read generic code from those who can write it.\n\nThis article takes you deep into how generics work with collections, why certain things are forbidden, and how to use wildcards effectively with the PECS principle.\n\n## 📋 At a Glance\n\n| Aspect | Details |\n|--------|---------|\n| Introduced | Java 5 (2004) |\n| Key Mechanism | Type erasure at compile time |\n| Wildcard Types | `?`, `? extends T`, `? super T` |\n| Key Principle | PECS (Producer Extends, Consumer Super) |\n| Common Pitfall | Raw types, heap pollution |\n\n---\n\n## 🎯 What You'll Learn\n\nAfter reading this article, you will be able to:\n\n- **Explain type erasure**: What happens to generics at runtime\n- **Use wildcards correctly**: Know when to use `extends` vs `super`\n- **Apply PECS**: Write flexible APIs that work with inheritance hierarchies\n- **Understand limitations**: Why `new T[]` and `instanceof T` don't work\n- **Avoid common mistakes**: Raw types, unchecked casts, heap pollution\n- **Read JDK source**: Understand complex generic signatures\n\n---\n\n## 🔥 Production Story: The ClassCastException Mystery\n\nA legacy codebase was being modernized. The team was adding generics to old collection code to improve type safety. Everything compiled, tests passed, but production started throwing `ClassCastException` in places that seemed impossible.\n\n**The problematic code:**\n\n```java\n// Legacy code (pre-generics)\npublic class OrderCache {\n private Map orders = new HashMap(); // Raw type!\n\n public void addOrder(String id, Order order) {\n orders.put(id, order);\n }\n\n public Order getOrder(String id) {\n return (Order) orders.get(id); // Cast required\n }\n}\n\n// \"Modernized\" code - but wrong!\npublic class PaymentService {\n private OrderCache cache;\n\n @SuppressWarnings(\"unchecked\") // ❌ Silencing the warning!\n public void processPayments() {\n Map orders = cache.getOrders(); // Returns raw Map\n\n // Developer adds payment records to \"orders\" map\n for (String id : orders.keySet()) {\n PaymentRecord payment = createPayment(orders.get(id));\n orders.put(id + \"_payment\", payment); // ❌ Puts PaymentRecord!\n }\n }\n}\n```\n\n**What went wrong:**\n\n```java\n// Later in another service...\nOrder order = cache.getOrder(\"ORD-123_payment\");\n// ClassCastException: PaymentRecord cannot be cast to Order!\n```\n\nThe raw `Map` allowed anything to be inserted. The generic `Map` assignment was unchecked, meaning the compiler trusted the developer. When non-Order objects were added, the corruption wasn't detected until much later.\n\n**The lesson:**\n\n```java\n// ✅ Proper fix: generics from the source\npublic class OrderCache {\n private Map orders = new HashMap<>(); // Parameterized!\n\n public void addOrder(String id, Order order) {\n orders.put(id, order);\n }\n\n public Order getOrder(String id) {\n return orders.get(id); // No cast needed\n }\n\n public Map getOrders() {\n return Collections.unmodifiableMap(orders); // Type-safe\n }\n}\n```\n\n**Never use `@SuppressWarnings(\"unchecked\")` without understanding exactly why it's safe.**\n\n---\n\n## 🧠 Mental Model: Generics as Compile-Time Guards\n\nThink of generics as security guards that only work during the day (compile time) and go home at night (runtime):\n\n```text\n┌─────────────────────────────────────────────────────────────────┐\n│ COMPILE TIME (Day Shift) │\n├─────────────────────────────────────────────────────────────────┤\n│ │\n│ Source Code: │\n│ List names = new ArrayList<>(); │\n│ names.add(\"Alice\"); │\n│ names.add(123); ← STOPPED! Guard says: \"123 is not String\" │\n│ │\n│ The generic guard checks every operation: │\n│ ✅ add(String) - allowed │\n│ ❌ add(Integer) - blocked at compile time │\n│ ✅ get() returns String - guaranteed │\n│ │\n└─────────────────────────────────────────────────────────────────┘\n │\n │ Compilation (guards go home)\n ↓\n┌─────────────────────────────────────────────────────────────────┐\n│ RUNTIME (Night Shift) │\n├─────────────────────────────────────────────────────────────────┤\n│ │\n│ Bytecode (type erased): │\n│ List names = new ArrayList(); // No generic info! │\n│ names.add(\"Alice\"); │\n│ │\n│ At runtime, the JVM doesn't know about │\n│ It's just a List holding Objects │\n│ │\n│ names instanceof List ← Can't check! Type is erased │\n│ new T[] ← Can't create! Don't know T │\n│ │\n└─────────────────────────────────────────────────────────────────┘\n```\n\n**Key insight:** Generics provide safety through compile-time checks, but the JVM never sees them. This is called **type erasure**.\n\n---\n\n## 🔬 Deep Dive\n\n### 1. Type Erasure: What Really Happens\n\nWhen Java compiles generic code, it removes all type parameters:\n\n```java\n// ✅ What you write:\npublic class Box {\n private T value;\n\n public T get() {\n return value;\n }\n\n public void set(T value) {\n this.value = value;\n }\n}\n\nList strings = new ArrayList<>();\nstrings.add(\"hello\");\nString s = strings.get(0);\n```\n\n```java\n// ✅ What the compiler produces (after erasure):\npublic class Box {\n private Object value; // T → Object\n\n public Object get() {\n return value;\n }\n\n public void set(Object value) {\n this.value = value;\n }\n}\n\nList strings = new ArrayList(); // Raw type\nstrings.add(\"hello\");\nString s = (String) strings.get(0); // Compiler inserts cast!\n```\n\n**Erasure rules:**\n- Unbounded `` → `Object`\n- Bounded `` → `Number`\n- Bounded `` → `Comparable` (first bound)\n\n### 2. Why Erasure? Backward Compatibility\n\nJava 5 needed generics to work with existing pre-generics code:\n\n```java\n// Pre-Java 5 code (still works!)\nList rawList = new ArrayList();\nrawList.add(\"hello\");\nrawList.add(123); // No error - raw type accepts anything\n\n// Java 5+ code\nList typedList = rawList; // Warning, but compiles\n// Allows gradual migration without breaking existing code\n```\n\n**Trade-off:** Backward compatibility came at the cost of runtime type information.\n\n### 3. Wildcards: The Three Flavors\n\n```java\n// ✅ Unbounded wildcard: ?\n// \"I accept any type, but I don't care what it is\"\npublic void printAll(List items) {\n for (Object item : items) {\n System.out.println(item);\n }\n // items.add(\"x\"); ← Can't add! Don't know the type\n}\n\n// ✅ Upper bounded: ? extends T\n// \"I accept T or any subtype of T\"\npublic double sumNumbers(List numbers) {\n double sum = 0;\n for (Number n : numbers) { // Can read as Number\n sum += n.doubleValue();\n }\n // numbers.add(1); ← Can't add! Might be List\n return sum;\n}\n\n// ✅ Lower bounded: ? super T\n// \"I accept T or any supertype of T\"\npublic void addIntegers(List list) {\n list.add(1); // ✅ Can add Integer (or subtypes)\n list.add(2);\n // Integer i = list.get(0); ← Can't read as Integer! Might be Object\n Object o = list.get(0); // Can only read as Object\n}\n```\n\n### 4. PECS: Producer Extends, Consumer Super\n\nThe most important principle for generic method design:\n\n```text\n┌─────────────────────────────────────────────────────────────────┐\n│ PECS PRINCIPLE │\n├─────────────────────────────────────────────────────────────────┤\n│ │\n│ If collection PRODUCES items (you read from it): │\n│ Use: │\n│ │\n│ List │\n│ ┌─────────────────────┐ │\n│ │ [1, 2.5, 3L] │ ─────→ Number out │\n│ └─────────────────────┘ (can read) │\n│ │\n│ If collection CONSUMES items (you write to it): │\n│ Use: │\n│ │\n│ List │\n│ ┌─────────────────────┐ │\n│ │ [ , , ] │ ←───── Integer in │\n│ └─────────────────────┘ (can write) │\n│ │\n│ If collection does BOTH: │\n│ Use exact type: │\n│ │\n└─────────────────────────────────────────────────────────────────┘\n```\n\n**Real example - Collections.copy():**\n\n```java\n// ✅ JDK implementation uses PECS perfectly\npublic static void copy(List dest, List src) {\n // src is PRODUCER → extends (read from it)\n // dest is CONSUMER → super (write to it)\n for (int i = 0; i < src.size(); i++) {\n dest.set(i, src.get(i));\n }\n}\n\n// Usage:\nList numbers = new ArrayList<>();\nList integers = Arrays.asList(1, 2, 3);\n\nCollections.copy(numbers, integers); // Works!\n// dest accepts Number or supertypes → Integer fits as Number\n// src produces Integer which IS-A Number\n```\n\n### 5. Why You Can't Create Generic Arrays\n\n```java\n// ❌ This is illegal\npublic T[] createArray(int size) {\n return new T[size]; // Compile error!\n}\n```\n\n**Why?** Arrays carry runtime type information; generics don't:\n\n```java\n// Arrays know their type at runtime\nString[] strings = new String[5];\nObject[] objects = strings; // Arrays are covariant\nobjects[0] = 123; // ArrayStoreException at RUNTIME!\n// JVM checks: 123 is Integer, array is String[] → Exception\n\n// If generic arrays were allowed:\nList[] stringLists = new List[5]; // Hypothetically\nObject[] objects = stringLists; // Would be allowed\nobjects[0] = new ArrayList(); // No runtime check possible!\n// JVM can't check: ArrayList vs ArrayList\n// Type erasure means both are just ArrayList at runtime\n```\n\n**Workaround:**\n\n```java\n// ✅ Use Array.newInstance with explicit class\n@SuppressWarnings(\"unchecked\")\npublic T[] createArray(Class componentType, int size) {\n return (T[]) Array.newInstance(componentType, size);\n}\n\n// ✅ Or return List instead of array\npublic List createList(int size) {\n return new ArrayList<>(size);\n}\n```\n\n### 6. Bridge Methods: How the JVM Handles Generics\n\nWhen you override a generic method, the compiler generates bridge methods:\n\n```java\n// ✅ Generic interface\ninterface Comparable {\n int compareTo(T other);\n}\n\n// ✅ Your implementation\nclass Name implements Comparable {\n private String value;\n\n @Override\n public int compareTo(Name other) { // Takes Name\n return this.value.compareTo(other.value);\n }\n}\n```\n\nAfter erasure, there's a problem:\n\n```java\n// After erasure, interface becomes:\ninterface Comparable {\n int compareTo(Object other); // Takes Object!\n}\n\n// But your class has:\nclass Name implements Comparable {\n int compareTo(Name other); // Takes Name - doesn't override!\n}\n```\n\n**The compiler generates a bridge method:**\n\n```java\n// What the compiler actually generates:\nclass Name implements Comparable {\n // Your method\n public int compareTo(Name other) {\n return this.value.compareTo(other.value);\n }\n\n // Bridge method (synthetic)\n public int compareTo(Object other) {\n return compareTo((Name) other); // Delegates to your method\n }\n}\n```\n\nYou can see bridge methods via reflection:\n\n```java\nfor (Method m : Name.class.getDeclaredMethods()) {\n System.out.println(m + \" isBridge: \" + m.isBridge());\n}\n// compareTo(Name) isBridge: false\n// compareTo(Object) isBridge: true\n```\n\n### 7. Heap Pollution\n\nHeap pollution occurs when a variable of a parameterized type refers to an object that is not of that type:\n\n```java\n// ❌ Heap pollution example\nList strings = new ArrayList<>();\naddToList(strings, 42); // Compiles with warning!\n\n@SuppressWarnings(\"unchecked\")\nstatic void addToList(List list, Object element) { // Raw type\n list.add(element); // Heap pollution! Integer in List\n}\n\n// Later...\nString s = strings.get(0); // ClassCastException!\n```\n\n**Avoiding heap pollution:**\n\n```java\n// ✅ Never use raw types\nstatic void addToList(List list, T element) {\n list.add(element); // Type-safe\n}\n\n// ✅ Be careful with varargs and generics\n@SafeVarargs // Promise that you don't pollute\nstatic List asList(T... elements) {\n List result = new ArrayList<>();\n for (T element : elements) {\n result.add(element);\n }\n return result;\n}\n```\n\n---\n\n## ⚠️ Common Mistakes\n\n### Mistake 1: Using Raw Types\n\n❌ **Problem:**\n```java\nList orders = new ArrayList(); // Raw type!\norders.add(new Order());\norders.add(\"not an order\"); // No compile error!\n\nOrder first = (Order) orders.get(0); // Cast required\nOrder second = (Order) orders.get(1); // ClassCastException!\n```\n\n✅ **Solution:**\n```java\nList orders = new ArrayList<>();\norders.add(new Order());\norders.add(\"not an order\"); // Compile error! Type safety.\n```\n\n---\n\n### Mistake 2: Comparing Generics at Runtime\n\n❌ **Problem:**\n```java\npublic boolean isList(Object obj) {\n return obj instanceof List; // Compile error!\n}\n\npublic boolean isStringList(Object obj) {\n return obj instanceof List; // Compile error!\n}\n```\n\n✅ **Solution:**\n```java\npublic boolean isList(Object obj) {\n return obj instanceof List; // Check raw type only\n}\n\n// For specific type checking, use explicit Class parameter\npublic boolean isListOf(Object obj, Class elementType) {\n if (!(obj instanceof List)) return false;\n List list = (List) obj;\n for (Object item : list) {\n if (item != null && !elementType.isInstance(item)) {\n return false;\n }\n }\n return true;\n}\n```\n\n---\n\n### Mistake 3: Ignoring PECS in API Design\n\n❌ **Problem:**\n```java\n// Too restrictive!\npublic void addAllNumbers(List source, List target) {\n target.addAll(source);\n}\n\n// Can't call with:\nList integers = Arrays.asList(1, 2, 3);\nList numbers = new ArrayList<>();\naddAllNumbers(integers, numbers); // Compile error! List != List\n```\n\n✅ **Solution:**\n```java\n// Using PECS\npublic void addAllNumbers(List source, // Producer\n List target) { // Consumer\n target.addAll(source);\n}\n\n// Now works!\nList integers = Arrays.asList(1, 2, 3);\nList numbers = new ArrayList<>();\naddAllNumbers(integers, numbers); // OK!\n\nList