Generics in Java

Series: Java Core for Beginners Lecture: 09 of 12 Topics: Why generics exist · Generic classes & methods · Type parameters · Bounded type parameters · Wildcards · Type erasure

The Problem Generics Solve

Before Java 5 introduced generics, the Collections Framework existed but worked with raw Object references. Every container held Object, and you had to cast elements back to their actual type when retrieving them:

// Pre-generics Java (Java 1.4 and earlier) — do not write this today
List names = new ArrayList();
names.add("Alice");
names.add("Bob");
names.add(42);            // adding an integer to a "names" list — no complaint from compiler

String first = (String) names.get(0);   // explicit cast required
String second = (String) names.get(2);  // ClassCastException at runtime! 42 is not a String

Two problems are obvious:

1. No type safety at compile time. The compiler had no way to enforce that a list of names should only contain strings. Bugs were discovered at runtime, not at compile time.
2. Casting noise everywhere. Every retrieval required a cast, cluttering the code and adding runtime overhead.

Generics solve both problems by letting you parameterize types — telling the compiler exactly what type a container holds, so it can enforce correctness at compile time and eliminate casts:

// With generics
List<String> names = new ArrayList<>();
names.add("Alice");
names.add("Bob");
names.add(42);   // COMPILE ERROR — int is not a String

String first = names.get(0);   // no cast needed — compiler knows it's a String

Generics are pervasive in modern Java. Every time you write List, Map, or Optional, you are using generics. Understanding how they work — and why they are designed the way they are — makes you a significantly more effective Java programmer.

Generic Classes

A generic class is parameterized by one or more type parameters declared in angle brackets after the class name. The type parameter is a placeholder that callers replace with a concrete type when they use the class.

Defining a generic class

Let us build a reusable Pair class that holds two values of potentially different types:

public class Pair<A, B> {

    private final A first;
    private final B second;

    public Pair(A first, B second) {
        this.first  = first;
        this.second = second;
    }

    public A getFirst()  { return first; }
    public B getSecond() { return second; }

    public Pair<B, A> swap() {
        return new Pair<>(second, first);
    }

    @Override
    public String toString() {
        return "(" + first + ", " + second + ")";
    }
}

Using the class:

Pair<String, Integer> nameAge = new Pair<>("Alice", 30);
System.out.println(nameAge.getFirst());    // "Alice"
System.out.println(nameAge.getSecond());   // 30
System.out.println(nameAge);              // (Alice, 30)

Pair<Integer, String> swapped = nameAge.swap();
System.out.println(swapped);              // (30, Alice)

Pair<String, String> coords = new Pair<>("40.7128° N", "74.0060° W");
System.out.println(coords);               // (40.7128° N, 74.0060° W)

Notice that the same Pair class works for any combination of types. Without generics you would need a separate class for every combination, or fall back to Object with all its problems.

A generic stack

Let us build a more realistic example — a generic stack (LIFO — last in, first out):

public class Stack<T> {

    private final List<T> elements = new ArrayList<>();

    public void push(T item) {
        elements.add(item);
    }

    public T pop() {
        if (isEmpty()) {
            throw new NoSuchElementException("Stack is empty.");
        }
        return elements.remove(elements.size() - 1);
    }

    public T peek() {
        if (isEmpty()) {
            throw new NoSuchElementException("Stack is empty.");
        }
        return elements.get(elements.size() - 1);
    }

    public boolean isEmpty() {
        return elements.isEmpty();
    }

    public int size() {
        return elements.size();
    }

    @Override
    public String toString() {
        return elements.toString();
    }
}

Using the generic stack:

Stack<Integer> intStack = new Stack<>();
intStack.push(10);
intStack.push(20);
intStack.push(30);
System.out.println(intStack);       // [10, 20, 30]
System.out.println(intStack.pop()); // 30
System.out.println(intStack.peek()); // 20
System.out.println(intStack.size()); // 2

Stack<String> strStack = new Stack<>();
strStack.push("hello");
strStack.push("world");
System.out.println(strStack.pop()); // "world"

The same Stack class works for integers, strings, custom objects — any type. The compiler guarantees that a Stack only ever holds integers and a Stack only ever holds strings.

The diamond operator

Since Java 7, the compiler can infer the type argument on the right side of an assignment — you only need to write <> (the diamond operator):

// Full form — redundant
Pair<String, Integer> p = new Pair<String, Integer>("Alice", 30);

// With diamond operator — type is inferred from the left side
Pair<String, Integer> p = new Pair<>("Alice", 30);

// Also inferred in variable declarations (Java 10+ with var)
var p = new Pair<>("Alice", 30);   // inferred as Pair<String, Integer>

Always use the diamond operator. Writing the type twice is redundant and adds noise.

Generics with primitives — autoboxing

Type parameters can only be reference types — not primitives. You cannot write Stack. Instead, use the corresponding wrapper class and rely on autoboxing:

Stack<Integer> intStack = new Stack<>();
intStack.push(42);          // autoboxing: int 42 → Integer.valueOf(42)
int value = intStack.pop(); // unboxing: Integer → int

Autoboxing and unboxing happen automatically — you rarely notice them. Be aware they exist for performance-sensitive code, since each boxing operation allocates a new wrapper object.

Generic Methods

A generic method has its own type parameters, independent of the class it belongs to. This lets you write type-safe utility methods without making the entire enclosing class generic.

Defining a generic method

The type parameter list goes before the return type:

public class ArrayUtils {

    // Generic method — T is the element type
    public static <T> void swap(T[] array, int i, int j) {
        T temp   = array[i];
        array[i] = array[j];
        array[j] = temp;
    }

    // Generic method returning a value
    public static <T> T lastElement(T[] array) {
        if (array == null || array.length == 0) {
            throw new NoSuchElementException("Array is empty.");
        }
        return array[array.length - 1];
    }

    // Generic method creating a List from varargs
    public static <T> List<T> listOf(T... elements) {
        List<T> result = new ArrayList<>();
        for (T element : elements) {
            result.add(element);
        }
        return result;
    }
}

Using generic methods:

String[] names = {"Alice", "Bob", "Charlie"};
ArrayUtils.swap(names, 0, 2);
System.out.println(Arrays.toString(names));   // [Charlie, Bob, Alice]

Integer[] numbers = {10, 20, 30, 40};
System.out.println(ArrayUtils.lastElement(numbers));   // 40

List<String> list = ArrayUtils.listOf("x", "y", "z");
System.out.println(list);   // [x, y, z]

Type inference for generic methods

The compiler infers the type parameter from the arguments passed. You rarely need to specify it explicitly:

// Explicit type — verbose, usually unnecessary
ArrayUtils.<String>swap(names, 0, 2);

// Inferred — cleaner
ArrayUtils.swap(names, 0, 2);

You only need explicit type specification in rare cases where the compiler cannot infer the type, such as when there are no method arguments to infer from.

A practical generic utility method

public class CollectionUtils {

    // Returns the first element matching a predicate, or null if none matches
    public static <T> T findFirst(List<T> list, java.util.function.Predicate<T> predicate) {
        for (T element : list) {
            if (predicate.test(element)) {
                return element;
            }
        }
        return null;
    }

    // Returns all elements matching a predicate
    public static <T> List<T> filter(List<T> list, java.util.function.Predicate<T> predicate) {
        List<T> result = new ArrayList<>();
        for (T element : list) {
            if (predicate.test(element)) {
                result.add(element);
            }
        }
        return result;
    }

    // Transforms all elements using a mapping function
    public static <T, R> List<R> map(List<T> list, java.util.function.Function<T, R> mapper) {
        List<R> result = new ArrayList<>();
        for (T element : list) {
            result.add(mapper.apply(element));
        }
        return result;
    }
}

List<String> names = List.of("Alice", "Bob", "Alexander", "Barbara", "Charlie");

String first = CollectionUtils.findFirst(names, n -> n.startsWith("A"));
System.out.println(first);   // "Alice"

List<String> aNames = CollectionUtils.filter(names, n -> n.startsWith("A"));
System.out.println(aNames);  // [Alice, Alexander]

List<Integer> lengths = CollectionUtils.map(names, String::length);
System.out.println(lengths); // [5, 3, 9, 7, 7]

This is precisely how the Stream API (Lecture 12) works internally — filter, map, and similar operations are generic methods built on the same foundations.

Type Parameters and Naming Conventions

By convention, type parameter names are single uppercase letters. The most common are:

These are conventions, not keywords — you could write List and it would compile. But following the conventions makes your code immediately readable to any Java developer.

For multiple parameters, separate with commas: Map, Function, BiFunction.

Bounded Type Parameters

Sometimes you want to accept any type, but only types that satisfy a certain constraint — for example, types that implement Comparable, or types that extend a specific class. Bounded type parameters express these constraints.

Upper bounded — extends

means T must be SomeType or any subclass/implementation of it:

// Only accepts types that implement Comparable — i.e., types that can be compared
public static <T extends Comparable<T>> T max(T a, T b) {
    return a.compareTo(b) >= 0 ? a : b;
}

System.out.println(max(10, 20));           // 20 — Integer implements Comparable
System.out.println(max("apple", "banana")); // "banana" — String implements Comparable
System.out.println(max(3.14, 2.71));       // 3.14 — Double implements Comparable

Without the bound, calling a.compareTo(b) would be a compile error because a plain T has no guarantee of having a compareTo method — it could be any type.

Multiple bounds

A type parameter can have multiple bounds separated by &:

// T must extend Animal AND implement Flyable
public static <T extends Animal & Flyable> void makeFlightSound(T creature) {
    creature.makeSound();   // from Animal
    creature.fly();         // from Flyable
}

With multiple bounds, at most one can be a class; the rest must be interfaces. The class must come first.

A generic min/max method with bounds

public static <T extends Comparable<T>> T min(List<T> list) {
    if (list == null || list.isEmpty()) {
        throw new IllegalArgumentException("List must not be empty.");
    }
    T minimum = list.get(0);
    for (T element : list) {
        if (element.compareTo(minimum) < 0) {
            minimum = element;
        }
    }
    return minimum;
}

System.out.println(min(List.of(5, 3, 8, 1, 9)));           // 1
System.out.println(min(List.of("zebra", "ant", "mouse")));  // "ant"

Why extends is used for both classes and interfaces in bounds

In the context of type bounds, extends means “is a subtype of”, covering both:

• Subclasses: — T must be Animal or any subclass
• Implementations: > — T must implement Comparable

This overloading of extends is a quirk of Java’s generic syntax. In type bounds, you always write extends, never implements.

Wildcards

Sometimes you want to write a method that accepts a collection of some type, but you do not need to know the exact type — you just need to read from it, or write to it. Wildcards (?) express “some unknown type.”

Unbounded wildcard —

means “a collection of some unknown type.” Use it when you only need to call methods defined on Object:

public static void printAll(List<?> list) {
    for (Object element : list) {
        System.out.println(element);
    }
}

printAll(List.of(1, 2, 3));           // works — List<Integer>
printAll(List.of("a", "b", "c"));     // works — List<String>
printAll(List.of(3.14, 2.71));        // works — List<Double>

You cannot add elements to a List (except null) because the compiler does not know the actual type — it cannot verify that whatever you add is safe.

Why List