Generics with Collections

Every mechanic in this series so far — generic classes, generic methods, bounds, wildcards — has mostly used small, invented types like Box<T> to keep the focus on the mechanism itself. In practice, though, the single most common place you'll actually use generics is Java's own collections framework. This lesson looks at List<T>, Set<T>, and Map<K, V> specifically, and closes a question "Wildcards" only motivated in passing: why exactly List<String> and List<Object> are unrelated types.

Generic Collections: List, Set, and Map

List<T>, Set<T>, and Map<K, V> are themselves ordinary generic types, built with exactly the mechanism covered in "Introduction to Generics" — List has one type parameter for its elements, Map has two, one for its keys and one for its values.

import java.util.List;
import java.util.Map;
import java.util.Set;

public class GenericCollectionApisExample {

    public static void main(String[] args) {
        // List<T>: an ordered, index-accessible sequence of one element type.
        List<String> names = List.of("Alice", "Bob", "Charlie");

        // Set<T>: an unordered collection of one element type, with no duplicates.
        Set<String> uniqueNames = Set.of("Alice", "Bob", "Alice"); // the duplicate collapses

        // Map<K, V>: an association from one key type to one value type.
        Map<String, Integer> ages = Map.of("Alice", 30, "Bob", 25);

        System.out.println("List: " + names);
        System.out.println("Set size: " + uniqueNames.size());
        System.out.println("Map: " + ages);

        // The exact same three interfaces -- List, Set, Map -- are generic
        // over ANY type; nothing here is specific to String or Integer.
        List<Integer> scores = List.of(90, 85, 78);
        Set<Boolean> flags = Set.of(true, false);
        System.out.println("Scores: " + scores);
        System.out.println("Flags: " + flags);
    }
}

The same three interfaces work identically regardless of what they hold — List<String> and List<Integer> are the same List, Set<String> and Set<Boolean> are the same Set. Nothing about the collection APIs themselves changes; only the type argument does.

Type Safety with Collections

The compile-time checking covered generally in "Introduction to Generics" applies to every collection operation — add, put, get — not just to construction.

import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

public class CollectionTypeSafetyExample {

    public static void main(String[] args) {
        List<String> names = new ArrayList<>();
        names.add("Alice");
        // names.add(42); // would NOT compile -- List<String> only accepts String

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

        Map<String, Integer> ages = new HashMap<>();
        ages.put("Alice", 30);
        // ages.put("Alice", "thirty"); // would NOT compile -- the value must be an Integer
        // ages.put(42, 30);            // would NOT compile -- the key must be a String

        int age = ages.get("Alice"); // no cast needed here either

        System.out.println(first + " is " + age);
    }
}

Both names.add(42) on a List<String> and ages.put("Alice", "thirty") on a Map<String, Integer> are rejected at compile time, before either mistake could ever reach a running program. Reading back with names.get(0) or ages.get("Alice") requires no cast, for the same reason — the compiler already knows exactly what type is stored.

Why List