Generics let you write a class, interface, or method once and use it safely with any type - the type becomes a parameter, just like a method parameter, but for the type system itself. Without generics, a list that stores any object works but loses all type information: you add a String, retrieve an Object, cast it, and hope nothing breaks at runtime. With generics, List<String> tells the compiler exactly what is inside - it prevents you from adding an Integer, removes the need for a cast when you retrieve, and catches mismatches at compile time rather than at three in the morning when a ClassCastException crashes production.

What Are Generics?

A generic type is a class, interface, or method declaration that has one or more type parameters — placeholders written in angle brackets that the caller fills in with a real type when using the class or calling the method.

WITHOUT GENERICS (pre-Java 5 style):

  class Box {
      private Object value;                 // stores anything

      void set(Object value) { ... }
      Object get() { return value; }        // returns Object - caller must cast
  }

  Box box = new Box();
  box.set("Hello");
  String s = (String) box.get();            // cast required - unsafe
  box.set(42);                              // no error - Integer also goes in
  String broken = (String) box.get();       // ClassCastException at RUNTIME

WITH GENERICS:

  class Box<T> {
      private T value;                      // T is the type parameter

      void set(T value) { ... }
      T get() { return value; }             // returns T - no cast needed
  }

  Box<String> box = new Box<>();
  box.set("Hello");
  String s = box.get();                     // no cast - compiler knows it's String
  box.set(42);                              // COMPILE ERROR - 42 is not a String

The letter T in Box<T> is called a type parameter. It is a placeholder - a variable for a type. When you write Box<String>, T becomes String throughout the class. When you write Box<Integer>, T becomes Integer. The class definition is written once; the type is supplied by the caller.

Basic Overview - The Four Things Every Developer Needs to Know

1. TYPE PARAMETERS - the placeholder syntax

   Fresher view  : <T> means "some type, to be decided by the caller"
                   You write it once in the declaration; the caller
                   fills it in. T, E, K, V, R are conventional letters
                   but any valid identifier works.

   Deeper view   : type parameters are erased at runtime (covered in
                   the Type Erasure article). At compile time, the
                   compiler uses them to verify type safety. At
                   runtime, a Box<String> and a Box<Integer> are both
                   just "Box" - the type argument is gone.

   Conventions:
     T  - general Type (most common single-type parameter)
     E  - Element (used in collections: List<E>, Set<E>)
     K  - Key (used in maps: Map<K, V>)
     V  - Value (used in maps: Map<K, V>)
     R  - Return type (used in functions: Function<T, R>)
     N  - Number (when T is constrained to number types)

2. RAW TYPES - generics without the type argument

   Fresher view  : List list = new ArrayList() is a "raw type" -
                   it compiles but the compiler cannot check what you
                   put in or take out. Every operation on it is
                   "unchecked" and the compiler warns you.

   Deeper view   : raw types exist only for backward compatibility
                   with pre-Java-5 code. Writing a raw type in new
                   code is never correct - it opts out of all the
                   type safety generics provide. Treat every raw-type
                   compiler warning as an error to fix, not suppress.

3. TYPE SAFETY - what generics enforce at compile time

   Fresher view  : with generics, the compiler knows what type is
                   inside a container and stops you from putting in
                   the wrong type or using the result without a cast.

   Deeper view   : the compiler performs "type checking" at every
                   generic call site. A method declared to return T
                   is checked to actually return the T the caller
                   declared. A method that accepts T is checked to
                   receive only T. These checks happen entirely at
                   compile time - the compiled bytecode has no T,
                   only Object (with implicit casts inserted by
                   the compiler where needed)

4. GENERIC vs PARAMETERIZED TYPE

   Fresher view  : Box<T> is the GENERIC type (the declaration with
                   the placeholder). Box<String> is the PARAMETERIZED
                   type (a specific use with String filling the slot).

   Deeper view   : Box<String> and Box<Integer> are different
                   parameterized types but the SAME generic type.
                   At runtime, after type erasure, they are both
                   represented by the single Class object Box.class.
                   Box<String>.class does not exist. This is why
                   new T() and instanceof T fail at runtime - the
                   T information is not there.

Why Generics Were Added to Java

Java 5 introduced generics in 2004, primarily to solve three problems that plagued pre-generics Java code:

Problem 1 — Unsafe casts everywhere. Every collection returned Object. Reading from a List required casting to the expected type, and any mismatch was only discovered at runtime as a ClassCastException. The cast was not verified at compile time; it was pure trust.

Problem 2 — No compiler assistance on container contents. A List that was meant to hold only String objects had no way to enforce that constraint. Any method receiving that List could add any Object to it, corrupting the assumption of the code that originally populated it.

Problem 3 — Verbose, error-prone boilerplate. Writing type-safe containers before Java 5 required either accepting Object everywhere or writing a separate StringList, IntegerList, OrderList class per type — duplicating all the logic for each.

Java

Try it out

// File: PreGenericsProblems.java

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

public class PreGenericsProblems {

    public static void main(String[] args) {

        System.out.println("=== Pre-generics: the cast problem ===");

        // Raw List - stores anything as Object
        List rawList = new ArrayList();
        rawList.add("Laptop");
        rawList.add("Tablet");
        rawList.add(42);       // Integer sneaks in - no warning from the compiler here

        for (Object item : rawList) {
            // Every retrieval needs a cast
            // The cast to String on an Integer causes ClassCastException at runtime
            try {
                String product = (String) item;
                System.out.println("Product: " + product);
            } catch (ClassCastException e) {
                System.out.println("ClassCastException on item: " + item
                    + " (" + item.getClass().getSimpleName() + ")");
            }
        }

        System.out.println();

        System.out.println("=== With generics: compile-time safety ===");

        // Parameterized List - stores only String
        List<String> productList = new ArrayList<>();
        productList.add("Laptop");
        productList.add("Tablet");
        // productList.add(42);  <- COMPILE ERROR: incompatible types
        // The compiler stops this before the program even runs

        for (String product : productList) {
            // No cast needed - the compiler already knows it is a String
            System.out.println("Product: " + product);
        }
    }
}

Output:
=== Pre-generics: the cast problem ===
Product: Laptop
Product: Tablet
ClassCastException on item: 42 (Integer)

=== With generics: compile-time safety ===
Product: Laptop
Product: Tablet

How Generic Types Work

Declaring a Generic Class

A generic class declares one or more type parameters in angle brackets immediately after the class name. These parameters can then be used anywhere in the class body where a type would normally appear - as field types, method parameter types, return types, and local variable types.

Java

Try it out

// File: GenericBoxDemo.java

public class GenericBoxDemo {

    // T is the type parameter - a placeholder for whatever type the caller specifies
    static class Box<T> {
        private T content;

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

        T getContent() {
            return content; // returns exactly T - no Object, no cast
        }

        void setContent(T content) {
            this.content = content;
        }

        boolean isEmpty() {
            return content == null;
        }

        @Override
        public String toString() {
            return "Box<" + (content == null ? "empty" : content.getClass().getSimpleName())
                + ">: " + content;
        }
    }

    public static void main(String[] args) {

        // T is bound to String for this instance
        Box<String> stringBox = new Box<>("Wireless Headphones");
        System.out.println(stringBox);
        String item = stringBox.getContent(); // no cast needed
        System.out.println("Retrieved: " + item.toUpperCase()); // can call String methods directly

        System.out.println();

        // T is bound to Integer for this instance
        Box<Integer> intBox = new Box<>(4999);
        System.out.println(intBox);
        int price = intBox.getContent();   // auto-unboxes Integer to int - no cast
        System.out.println("Price + GST: Rs." + (price * 1.18));

        System.out.println();

        // T is bound to Box<String> - generics can be nested
        Box<Box<String>> boxOfBox = new Box<>(stringBox);
        System.out.println("Outer: " + boxOfBox);
        System.out.println("Inner: " + boxOfBox.getContent().getContent());

        System.out.println();

        // COMPILE ERRORS - uncommenting either line would fail at compile time
        // Box<String> broken = new Box<>(42);       // 42 is not a String
        // Integer wrong = stringBox.getContent();   // getContent() returns String, not Integer
        System.out.println("Type safety verified at compile time - no errors above");
    }
}

Output:
Box<String>: Wireless Headphones
Retrieved: WIRELESS HEADPHONES

Box<Integer>: 4999
Price + GST: Rs.5898.82

Outer: Box<Box>: Box<String>: Wireless Headphones
Inner: Wireless Headphones

Type safety verified at compile time - no errors above

Multiple Type Parameters

A class can declare multiple type parameters, each separated by a comma. Map<K, V> is the canonical example from the JDK - two distinct type parameters, one for keys and one for values.

Java

Try it out

// File: MultipleTypeParamsDemo.java

public class MultipleTypeParamsDemo {

    // Two type parameters - K for key, V for value
    static class Pair<K, V> {
        private final K key;
        private final V value;

        Pair(K key, V value) {
            this.key = key;
            this.value = value;
        }

        K getKey()   { return key;   }
        V getValue() { return value; }

        @Override
        public String toString() {
            return "Pair(" + key + ", " + value + ")";
        }
    }

    public static void main(String[] args) {
        // K=String, V=Integer
        Pair<String, Integer> productPrice = new Pair<>("Laptop Stand", 1299);
        System.out.println(productPrice);
        System.out.println("Key type  : " + productPrice.getKey().getClass().getSimpleName());
        System.out.println("Value type: " + productPrice.getValue().getClass().getSimpleName());

        System.out.println();

        // K=Integer, V=String - order matters
        Pair<Integer, String> idToStatus = new Pair<>(1001, "SHIPPED");
        System.out.println(idToStatus);

        System.out.println();

        // K=String, V=Pair<String,Integer> - nested parameterization
        Pair<String, Pair<String, Integer>> productDetail =
            new Pair<>("PROD-501", new Pair<>("Wireless Mouse", 799));
        System.out.println(productDetail);
        System.out.println("Inner value: " + productDetail.getValue().getValue());
    }
}

Output:
Pair(Laptop Stand, 1299)
Key type  : String
Value type: Integer

Pair(1001, SHIPPED)

Pair(PROD-501, Pair(Wireless Mouse, 799))
Inner value: 799

Raw Types and Why They Are Dangerous

A raw type is a generic class used without its type argument - Box instead of Box<String>. The compiler accepts it (for backward compatibility with pre-Java-5 code) but issues unchecked warnings, and the entire type-safety guarantee is gone.

Java

Try it out

// File: RawTypeDemo.java

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

public class RawTypeDemo {

    static class Box<T> {
        private T content;
        Box(T content) { this.content = content; }
        T getContent() { return content; }
    }

    public static void main(String[] args) {

        System.out.println("=== Raw type - all safety lost ===");

        // Raw type - no type argument. Compiler warns but compiles.
        Box rawBox = new Box("original string"); // unchecked warning
        rawBox = new Box(12345);                 // reassign to Integer - no warning

        // The compiler cannot know what getContent() returns - it becomes Object
        Object rawContent = rawBox.getContent();
        System.out.println("Raw content: " + rawContent);

        // This cast is UNCHECKED - if the type is wrong, ClassCastException at runtime
        try {
            String wrongCast = (String) rawBox.getContent(); // ClassCastException
        } catch (ClassCastException e) {
            System.out.println("ClassCastException: raw type had Integer, cast expected String");
        }

        System.out.println();

        System.out.println("=== Parameterized type - safety restored ===");

        // Parameterized - compiler knows T=String
        Box<String> typedBox = new Box<>("original string");
        // typedBox = new Box<>(12345); // COMPILE ERROR - cannot reassign to Box<Integer>
        String typedContent = typedBox.getContent(); // no cast, no exception possible
        System.out.println("Typed content: " + typedContent.toUpperCase());

        System.out.println();

        System.out.println("=== Heap pollution - mixing raw and generic ===");
        List<String> names = new ArrayList<>();
        names.add("Ananya");
        names.add("Rahul");

        // Assigning to a raw List reference "loses" the type information
        // but the underlying List<String> object is unchanged
        List rawNames = names; // unchecked assignment warning
        rawNames.add(42);      // Integer added to a List<String> - no immediate error

        // The ClassCastException appears when the Integer is READ through
        // the typed reference - the bug appears far from where it was caused
        try {
            for (String name : names) { // ClassCastException on Integer element
                System.out.println(name);
            }
        } catch (ClassCastException e) {
            System.out.println("Heap pollution: " + e.getMessage());
        }
    }
}

Output:
=== Raw type - all safety lost ===
Raw content: 12345
ClassCastException: raw type had Integer, cast expected String

=== Parameterized type - safety restored ===
Typed content: ORIGINAL STRING

=== Heap pollution - mixing raw and generic ===
Ananya
Rahul
Heap pollution: class java.lang.Integer cannot be cast to class java.lang.String

The Compiler's Role in Generic Type Safety

WHAT THE COMPILER DOES WITH GENERICS:

  Box<String> box = new Box<>("hello");

  Step 1 - TYPE ARGUMENT CAPTURE:
    The compiler records T = String for this Box instance.

  Step 2 - CALL SITE VERIFICATION:
    Every call to box.set(X) is checked: is X a String?
    Every call to box.get() is typed as String, not Object.

  Step 3 - IMPLICIT CAST INSERTION:
    box.get() returns T, which compiles to Object in bytecode.
    The compiler inserts a CHECKCAST instruction automatically,
    so "String s = box.get()" becomes "String s = (String) box.get()"
    in the compiled bytecode - but only after verifying no type error
    exists at the source level.

  Step 4 - ERASURE:
    T is replaced with Object (or its bound, if bounded) in bytecode.
    Box<String> and Box<Integer> compile to identical bytecode.
    At runtime: box.getClass() == Box.class, always.

THE TYPE SYSTEM'S GUARANTEE:
  If a Java program compiles without unchecked warnings, and all
  libraries it uses were also compiled without unchecked warnings,
  then no ClassCastException from generic code can occur at runtime
  (unless a cast is explicitly written in application code).
  The casts are there in the bytecode - they are just correct,
  because the compiler verified they must be.

Real-World Example - Flipkart Generic Repository Pattern

A product catalog service needs to perform the same operations - find by ID, save, delete, and list all - on several different entity types: Product, Seller, Review. Without generics, a separate repository class with identical code would need to be written for each type. With generics, one Repository<T, ID> captures the entire pattern, and each concrete repository specifies its types.

Java

Try it out

// File: Repository.java

import java.util.List;
import java.util.Optional;

// T  - the entity type this repository manages
// ID - the type of the entity's identifier
public interface Repository<T, ID> {
    void save(T entity);
    Optional<T> findById(ID id);
    List<T> findAll();
    void delete(ID id);
    int count();
}

Java

Try it out

// File: Product.java

public class Product {
    private final String productId;
    private final String name;
    private final double price;

    public Product(String productId, String name, double price) {
        this.productId = productId;
        this.name = name;
        this.price = price;
    }

    public String getProductId() { return productId; }
    public String getName()      { return name; }
    public double getPrice()     { return price; }

    @Override
    public String toString() {
        return "Product[" + productId + ", " + name + ", Rs." + price + "]";
    }
}

Java

Try it out

// File: InMemoryProductRepository.java

import java.util.*;

// T=Product, ID=String - this class works only with Product entities
// identified by String IDs. The Repository<T,ID> contract is satisfied
// by filling in both type parameters concretely.
public class InMemoryProductRepository implements Repository<Product, String> {

    private final Map<String, Product> store = new LinkedHashMap<>();

    @Override
    public void save(Product product) {
        store.put(product.getProductId(), product);
    }

    @Override
    public Optional<Product> findById(String productId) {
        return Optional.ofNullable(store.get(productId));
    }

    @Override
    public List<Product> findAll() {
        return List.copyOf(store.values());
    }

    @Override
    public void delete(String productId) {
        store.remove(productId);
    }

    @Override
    public int count() {
        return store.size();
    }
}

Java

Try it out

// File: GenericRepositoryDemo.java

public class GenericRepositoryDemo {

    public static void main(String[] args) {
        InMemoryProductRepository repo = new InMemoryProductRepository();

        System.out.println("=== Saving products ===");
        repo.save(new Product("PROD-001", "Wireless Headphones", 2499.0));
        repo.save(new Product("PROD-002", "Laptop Stand", 1299.0));
        repo.save(new Product("PROD-003", "USB-C Hub", 1799.0));
        System.out.println("Saved " + repo.count() + " products");

        System.out.println();

        System.out.println("=== Finding by ID ===");
        repo.findById("PROD-002").ifPresent(p ->
            System.out.println("Found: " + p));
        repo.findById("PROD-999").ifPresentOrElse(
            p -> System.out.println("Found: " + p),
            () -> System.out.println("PROD-999: not found"));

        System.out.println();

        System.out.println("=== Listing all products ===");
        repo.findAll().forEach(p -> System.out.println("  " + p));

        System.out.println();

        System.out.println("=== Deleting a product ===");
        repo.delete("PROD-001");
        System.out.println("Remaining count: " + repo.count());
        repo.findAll().forEach(p -> System.out.println("  " + p));
    }
}

Output:
=== Saving products ===
Saved 3 products

=== Finding by ID ===
Found: Product[PROD-002, Laptop Stand, Rs.1299.0]
PROD-999: not found

=== Listing all products ===
  Product[PROD-001, Wireless Headphones, Rs.2499.0]
  Product[PROD-002, Laptop Stand, Rs.1299.0]
  Product[PROD-003, USB-C Hub, Rs.1799.0]

=== Deleting a product ===
Remaining count: 2
  Product[PROD-002, Laptop Stand, Rs.1299.0]
  Product[PROD-003, USB-C Hub, Rs.1799.0]

Repository<T, ID> is written once. InMemoryProductRepository uses it with Product and String. A SellerRepository would use it with Seller and Long. A ReviewRepository with Review and UUID. Zero duplication of the contract definition. This is the pattern Spring Data JPA's JpaRepository<T, ID> is built on - the same interface the whole industry uses for repository-layer design.

Generic Naming Conventions

Letter	Meaning	Common Use
`T`	Type	Most general single type parameter - `Box<T>`, `Optional<T>`
`E`	Element	Types that represent elements in collections - `List<E>`, `Set<E>`
`K`	Key	Key in a key-value pair - `Map<K, V>`
`V`	Value	Value in a key-value pair - `Map<K, V>`
`R`	Return type	Return type in functional interfaces - `Function<T, R>`
`N`	Number	When the type is constrained to numeric types
`A`	Accumulator	Used in collectors and fold operations
`S`, `U`	Second, third	When multiple types are needed beyond T - `BiFunction<T, U, R>`

These are conventions, not rules enforced by the compiler. Box<Foo> compiles. But deviating from the convention without reason makes code harder to read - readers expect E in collection-like classes and K, V in map-like ones.

Best Practices

Always use the specific parameterized type rather than the raw type. List<String> instead of List. Map<String, Integer> instead of Map. The raw type silences every type-safety guarantee generics provide, makes code harder to read, and produces unchecked warnings that accumulate in the build output until everyone stops noticing them. Every unchecked warning is a potential ClassCastException deferred to runtime.

Use standard naming conventions for type parameters. T, E, K, V, R are recognized instantly by any Java developer. A parameter named MyType or DataObject requires the reader to stop and decide whether it is a concrete type or a type parameter, which is a completely avoidable cognitive load.

Keep type parameter lists short. One or two type parameters is normal. Three is occasionally necessary (some function types in streams). More than three is almost always a sign that the design can be simplified - either the class is doing too much, or some of the type relationships can be expressed through bounded parameters rather than separate free variables.

Understand that generics are a compile-time feature only. There is no List<String> at runtime - only List. This is not a limitation to work around; it is the design. The implications (no new T(), no instanceof T, no T[]) are covered fully in the Type Erasure and What Generics Cannot Do articles. The practical takeaway here: do not expect runtime type information from generics.

Common Mistakes

Mistake 1 - Using Raw Types in New Code

Java

Try it out

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

// WRONG - raw List accepts everything, returns Object,
// and produces unchecked warnings throughout
List products = new ArrayList();
products.add("Laptop");
products.add(1299); // no error - Integer added silently

// Every retrieval needs an unsafe cast
String name = (String) products.get(0); // works here by luck
String price = (String) products.get(1); // ClassCastException at runtime

// CORRECT - parameterized type enforces the constraint at compile time
List<String> productNames = new ArrayList<>();
productNames.add("Laptop");
// productNames.add(1299); // COMPILE ERROR - caught immediately
String productName = productNames.get(0); // no cast needed

Mistake 2 - Treating Generic Type Arguments as Inherited Types

Java

Try it out

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

// WRONG ASSUMPTION - because Integer extends Number, a developer
// might expect List<Integer> to be usable where List<Number> is required.
// It is NOT. Generic types are INVARIANT - List<Integer> and List<Number>
// are completely unrelated types even though Integer extends Number.
static void printNumbers(List<Number> numbers) {
    numbers.forEach(System.out::println);
}

List<Integer> integers = List.of(1, 2, 3);
// printNumbers(integers); // COMPILE ERROR
// "incompatible types: List<Integer> cannot be converted to List<Number>"

// CORRECT - use a bounded wildcard if any Number subtype should work.
// Wildcards are covered in their own articles; here is the fix:
static void printAnyNumbers(List<? extends Number> numbers) {
    numbers.forEach(System.out::println);
}

printAnyNumbers(integers); // now works - Integer IS-A Number satisfies ? extends Number

Mistake 3 - Confusing Parameterized Instances With Their Types

Java

Try it out

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

// WRONG - a common beginner assumption is that Box<String>.class
// exists as a distinct Class object from Box<Integer>.class
// At runtime, after type erasure, there is ONLY Box.class
class Box<T> { T value; }

// This does not compile:
// Class<Box<String>> c = Box<String>.class; // SYNTAX ERROR - not valid

// Box<String> and Box<Integer> have the SAME class at runtime:
Box<String> stringBox = new Box<>();
Box<Integer> intBox   = new Box<>();
System.out.println(stringBox.getClass() == intBox.getClass()); // prints: true
System.out.println(stringBox.getClass().getName());             // prints: Box (no type argument)

// CORRECT understanding: the type argument exists only at compile time.
// At runtime, instanceof and .class see only the raw class.
// Use instanceof with the raw class:
System.out.println(stringBox instanceof Box); // true - raw type check is valid
// System.out.println(stringBox instanceof Box<String>); // COMPILE ERROR in most contexts

Mistake 4 - Ignoring Unchecked Warnings With @SuppressWarnings("unchecked")

Java

Try it out

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

// WRONG - suppressing unchecked warnings without understanding why
// they appear. Each one is a potential ClassCastException at runtime.
// Blanket suppression hides real bugs.
@SuppressWarnings("unchecked")
static List<String> unsafeConvert(List<?> input) {
    return (List<String>) input; // unsafe cast - ClassCastException if input is List<Integer>
}

// CORRECT - when an unchecked operation is unavoidable (rare, usually
// in framework-level generic utilities), document WHY it is safe and
// use the narrowest possible scope for the suppression
@SuppressWarnings("unchecked")
static <T> T firstElement(List<?> list) {
    // Safe: this method's caller controls T and the list type at the
    // call site. If misused, the ClassCastException will appear at
    // the call site, not buried here.
    return (T) list.get(0);
}

Interview Questions

Q1. What are generics in Java, and what problem do they solve?

Generics allow classes, interfaces, and methods to declare type parameters - placeholders for types that the caller specifies at the usage site. They solve three problems that existed before Java 5: unsafe casts that caused ClassCastException at runtime when a collection returned Object, no compile-time checking of what types went into a container, and the need to write separate classes for each type a container needed to support. With generics, List<String> tells the compiler exactly what is inside - it prevents adding the wrong type, eliminates the need for casts when reading, and turns type mismatches from runtime errors into compile errors.

Q2. What is the difference between a generic type and a parameterized type?

A generic type is the declaration - class Box<T> or interface Repository<T, ID> - with one or more type parameters as placeholders. A parameterized type is a specific use of a generic type with real types supplied for the parameters - Box<String>, Repository<Product, Long>. The generic type is written once; parameterized types are the concrete uses. At runtime, after type erasure, all parameterized types of the same generic type share a single Class object - Box<String> and Box<Integer> are both just Box.class at runtime.

Q3. What is a raw type in Java, and why is it dangerous?

A raw type is a generic class or interface used without its type argument - List instead of List<String>, Box instead of Box<Integer>. The compiler accepts raw types for backward compatibility with pre-Java-5 code but issues unchecked warnings. A raw type is dangerous because it loses all compile-time type safety: the compiler cannot check what is put into or retrieved from it, every retrieval returns Object requiring an explicit cast, and wrong-type elements can be added without compile-time error, causing ClassCastException at runtime - often far from the point where the incorrect element was inserted. Writing raw types in new code is never correct.

Q4. Why is List not a subtype of List, even though Integer extends Number?

Generic types in Java are invariant - List<Integer> and List<Number> are completely unrelated types even though Integer is a subtype of Number. The reason is type safety: if List<Integer> were a List<Number>, you could assign a List<Integer> to a List<Number> reference and then add a Double (which is also a Number) to it - corrupting the original List<Integer>. Java's type system prevents this by making the relationship between generic parameterizations invariant. When covariant behavior is intentional, bounded wildcards (List<? extends Number>) are the correct mechanism - they allow reading but prevent writing.

Q5. What naming conventions are used for type parameters, and why do they matter?

The conventional single-letter names are T for a general type, E for element (used in collections), K and V for key and value (used in maps), and R for return type (used in functional interfaces). These conventions matter because they communicate the intended role of the type parameter immediately to any Java developer reading the code. Map<K, V> is instantly understood; Map<KeyType, ValueType> requires a reader to verify whether KeyType is a concrete class or a type parameter. Conventions reduce cognitive load - readers should not need to look up declarations to understand whether a name is a type or a type parameter.

Q6. How does the compiler enforce type safety with generics, and what does it mean that generics are a compile-time feature?

The compiler tracks the type argument supplied at each generic usage site and uses it to verify every operation on that parameterized type - every argument passed to a generic method, every value returned from one. When Box<String> is used, the compiler knows get() returns String and set() accepts only String. It inserts implicit CHECKCAST bytecode instructions where needed and rejects type mismatches as compile errors. At runtime, after type erasure, the type argument is gone - Box<String> and Box<Integer> compile to identical bytecode, both using Object where T appeared. The guarantee is entirely compile-time: if the code compiled without unchecked warnings, the inserted casts will not fail, because the compiler already verified they are correct.

FAQs

Can I use primitive types like int or double as type arguments?

No - type arguments must be reference types. Box<int> is a compile error; Box<Integer> is correct. Java's autoboxing and unboxing handle the conversion automatically in most cases: Box<Integer> box = new Box<>(42) compiles because 42 is autoboxed to Integer. The restriction exists because generics use Object as the erased type internally, and primitives are not Object. For performance-critical code with large numbers of primitive values, collections like IntStream or third-party libraries with primitive specializations avoid the boxing overhead.

Can a type parameter be used as the type of a static field?

No. A static field belongs to the class itself, not to any instance, and all instances share the same static field. Box<String> and Box<Integer> are different parameterized types but the same class at runtime - a static field on the class cannot be both String and Integer for different parameterizations simultaneously. The compiler therefore rejects static T staticField inside class Box<T>. Static methods can, however, declare their own independent type parameters: static <T> Box<T> empty() is valid because T here belongs to the method, not the class.

Does ArrayList have a different Class object than ArrayList at runtime?

No. Both have the same Class object - java.util.ArrayList.class. This is type erasure: the type argument String or Integer exists only in the source code and in the compiler's type-checking phase. After compilation, both are represented by the same raw bytecode class. This is why list.getClass() returns ArrayList.class for both, and why new ArrayList<String>().getClass() == new ArrayList<Integer>().getClass() evaluates to true.

What is heap pollution in the context of generics?

Heap pollution occurs when a variable of a parameterized type refers to an object that is not actually of that type - for example, when a List<String> reference ends up pointing to a list that actually contains non-String elements, because somewhere raw types or unsafe casts were used to bypass the type system. The pollution is called "heap" because the problem exists in the runtime heap state even though the type parameter information is supposed to express what is there. It typically surfaces as a ClassCastException in code that only reads from the collection and never performs any explicit cast - the cast was inserted by the compiler as part of generic type erasure, and it fails because the heap state was corrupted earlier through a raw-type or unchecked operation.

Can a generic class extend another generic class?

Yes, and there are two common patterns. A generic subclass can pass its own type parameter to the parent: class TypedBox<T> extends Box<T> makes TypedBox<String> extend Box<String>. Alternatively, a concrete subclass can fix the parent's type parameter: class StringBox extends Box<String> creates a non-generic class that is always a Box<String>. Both are valid and appear throughout the JDK — ArrayList<E> extends AbstractList<E> (first pattern), while Properties extends Hashtable<Object,Object> (second pattern).

What is the wildcard <?> and how does it differ from a type parameter ?

A type parameter <T> is declared by the class or method and is bound to a specific type at the usage site — Box<T> lets the caller choose T. A wildcard <?> is used at a call site to say "some type, I don't know or care which" — Box<?> accepts a Box of any type but does not name or bind that type, so you cannot add to or read typed values from it. A type parameter is about declaration; a wildcard is about consumption. Wildcards are covered in depth in the Wildcards article in this series.

Summary

Generics are Java's answer to writing type-safe, reusable code. A type parameter - the <T> in Box<T> or Repository<T, ID> - is a placeholder that the caller fills in when using the class or calling the method. The compiler tracks that type argument at every usage site, prevents type mismatches at compile time, and inserts verified casts where the bytecode needs them. What makes it work is entirely a compile-time mechanism: at runtime, after type erasure, Box<String> and Box<Integer> are both just Box.

The single most important habit this topic builds: reach for the parameterized type every time, never the raw type. List<String> over List. Map<String, Integer> over Map. Each raw type is a silent withdrawal from the type-safety contract that makes the rest of the code reliable - and the ClassCastException it eventually causes will appear somewhere completely unrelated to the raw type that caused it.

Everything else in the Generics series - bounded type parameters, wildcards, PECS, type erasure, and the restrictions that follow from it - builds directly on the foundation this article covers.

What to Read Next

Continue Learning Generics

Next Step

Why Generics?

Learn the problem generics were created to solve.

→

HashSet

Learn how to store a collection with no duplicate values.

→

Generic Classes

Learn how to write a class that works with any data type.

→

What Generics Cannot Do

Learn the things generics in Java won't let you do.

→

←

PreviousTreeMap Internal Working

NextWhy Generics?

→