Wildcards and PECS

For this lesson, we'll focus on the parts that show up in code reviews and interviews: invariance, unbounded ?, upper-bounded ? extends T, lower-bounded ? super T, PECS, Collections.copy, stack APIs, Comparator<? super T>, wildcard capture, return-type mistakes, and how Java's use-site variance compares with Kotlin and C#. We'll lean on the basics from Generics basics and the runtime story from How type erasure works rather than repeating them.

01Picture it first: three lanes through the same hierarchy

Let's get the picture right first. Imagine Object, Number and Integer as a type hierarchy, then put a list gate in front of it. An extends gate lets values flow out toward a wider type, while a super gate lets specific values flow in toward a wider container.

Fig. 1

Object, Number and Integer hierarchy with extends arrows showing safe reads upward and super arrows showing safe writes downward

Notice the direction. ? extends Number accepts a List<Integer>, but the compiler refuses add(10) because the real list might be List<Double>. ? super Integer accepts a List<Number> or List<Object>, so adding an Integer is safe, but reading gives only Object because the actual stored values might be any supertype's mixture.

02Wildcards under the hood: invariance first

Java arrays are covariant: a String[] can be treated as an Object[], and a bad store fails at runtime with ArrayStoreException. Generics took the other road. A List<Integer> is not a subtype of List<Number>, so the bad store fails at compile time.

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

List<Integer> integers = new ArrayList<>();
integers.add(10);

// If this were allowed, the next line would corrupt integers.
// List<Number> numbers = integers;
// numbers.add(3.14);

Integer first = integers.getFirst();

Notice three things:

• Integer extends Number, but List<Integer> does not extend List<Number>.
• Invariance protects writes. Without it, a list promised to contain integers could receive a Double.
• Wildcards are Java's way to recover flexibility without giving up type safety.

The unbounded wildcard, List<?>, is the most honest signature when the element type genuinely does not matter. You can read elements, but the best static type is Object. You can add only null, because null belongs to every reference type.

import java.util.List;

static int countNonNull(List<?> values) {
    int count = 0;
    for (Object value : values) {
        if (value != null) count++;
    }
    return count;
}

static void addMarker(List<?> values) {
    values.add(null);          // legal, but rarely useful
    // values.add("x");       // compile error: element type is unknown
}

I use List<?> for operations like size, isEmpty, logging, metrics and membership checks where I don't care whether the list holds Order, String or UUID. The simple option is List<Object>, but that rejects List<String>, which is almost never what you wanted.

03? extends T: producer, readable, not writable

? extends Number means "some specific type that is Number or below". The compiler knows every element can be viewed as a Number, so reads are safe. It does not know which exact subtype the list owns, so writing a non-null value is unsafe.