Wildcards

Unbounded, upper-bounded, and lower-bounded wildcards — plus the PECS rule that makes real generic APIs practical.

1. Definition

What is it?

A wildcard represents an unknown generic type.

Instead of saying “this is exactly a List<String>,” a wildcard lets you say “this is some kind of List, but I do not know the exact element type here.”

The most common forms are:

• <?>
• <? extends T>
• <? super T>

Wildcards are essential because Java generics is invariant.

That means List<Integer> is not a subtype of List<Number> even though Integer is a subtype of Number.

Why does it exist?

Without wildcards, many reusable APIs would be either too restrictive or unsafe.

For example, a method that only wants to read values from a list of numbers should not require exactly List<Number>.

It should also accept List<Integer>, List<Double>, and other numeric lists.

Wildcards express that relationship safely.

Where does it fit?

Wildcards sits between generic basics and type erasure in terms of conceptual difficulty.

It matters heavily in:

• library API design
• collection utilities
• stream and comparator helpers
• framework extension points
• interview questions about variance and substitutability

If generics basics is about parameterizing a type, wildcards is about how different parameterized types cooperate.

2. Core Concepts

2.1 Invariance first

2.1.1 Keywords and contracts you should make explicit here

Wildcards become clearer if you deliberately name the contract words behind them:

• invariance — List<Integer> is not a subtype of List<Number>.
• unbounded wildcard — <?>, meaning an unknown type with mainly read-as-Object semantics.
• upper-bounded wildcard — <? extends T>, used when values are produced for reading.
• lower-bounded wildcard — <? super T>, used when values are consumed through writes.
• producer — a parameter you mainly read from.
• consumer — a parameter you mainly write to.
• PECS — shorthand for Producer Extends, Consumer Super.
• wildcard capture — the compiler technique that lets a helper method treat one unknown wildcard as a consistent internal type variable.

These words are part of the API contract. A good signature tells the caller whether the parameter is read-oriented, write-oriented, or both.

Before wildcards, you must understand invariance.

List<Integer> integers = List.of(1, 2, 3);
// List<Number> numbers = integers; // compilation error

Java forbids that assignment because allowing writes through List<Number> would be unsafe.

If it were allowed, you could add a Double into a List<Integer>.

Wildcards gives controlled flexibility without breaking safety.

2.2 Unbounded wildcard ``

<?> means “some unknown type.”

It is useful when:

• the code only needs the object as a container
• you only call methods that do not depend on the concrete element type
• you mostly read values as Object

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

You can read from List<?> as Object.

You cannot safely add arbitrary elements to it, because the element type is unknown.

2.3 Upper-bounded wildcard ``

This form means “some unknown subtype of T.”

It is ideal when the structure produces values for you.

public static double sum(List<? extends Number> values) {
    double total = 0;
    for (Number value : values) {
        total += value.doubleValue();
    }
    return total;
}

This method can accept:

• List<Integer>
• List<Long>
• List<Double>
• List<Number>

The key restriction is write safety.

You usually cannot add values to a List<? extends Number> because the actual subtype is unknown.

2.4 Lower-bounded wildcard ``

This form means “some unknown supertype of T.”

It is ideal when the structure consumes values from you.

public static void addDefaults(List<? super Integer> target) {
    target.add(0);
    target.add(1);
}

This method can accept:

• List<Integer>
• List<Number>
• List<Object>

You can safely add Integer values.

But when reading back, the compiler can only promise Object, because the precise stored type is not known.

2.5 PECS

PECS stands for:

• Producer Extends
• Consumer Super

It is a memory aid, not a formal language rule.

Use extends when:

• you mainly read values
• the source structure produces values for your algorithm

Use super when:

• you mainly write values
• the target structure consumes values from your algorithm

This is probably the single most important wildcard interview rule.

2.6 Wildcard capture

Sometimes a wildcard API is correct externally, but the implementation needs a concrete type parameter internally.

That is when helper methods with their own type parameter become useful.

public static void swapFirstTwo(List<?> list) {
    swapHelper(list);
}

private static <T> void swapHelper(List<T> list) {
    T first = list.get(0);
    list.set(0, list.get(1));
    list.set(1, first);
}

This technique is called wildcard capture.

The helper method lets the compiler “capture” the unknown wildcard as one consistent type.

2.7 Why `List