Generic Wildcards — Recognize wildcard usage at a high level (<?>, <? extends T>) (intro)

Before Java introduced generics, programmers stored objects in collections like ArrayList without any type information. Every item that came out of a collection was just an Object, and you had to manually cast it to the correct type. This led to runtime errors that the compiler could never catch for you. Generics fixed that problem by letting you declare what type a collection holds, such as ArrayList<String>. But generics introduced a new question: what do you do when you want to write a method that works with any kind of list, regardless of the type inside it?

That question is exactly what wildcard types were designed to answer. Wildcards, written with the ? symbol, allow you to write flexible code that accepts a variety of generic types while keeping the safety guarantees that generics provide. Let's trace the timeline of how this feature came to be.

The core question that wildcards address is this: if Dog is a subclass of Animal, why isn't List<Dog> a subtype of List<Animal>? Understanding this puzzle is the key to understanding why wildcards exist.

To understand wildcards, you first need to grasp a counterintuitive rule in Java generics called invariance. Even though Integer extends Number, a List<Integer> is not a subtype of List<Number>. Java enforces this to prevent type-safety violations. Wildcards are the tool that lets you relax this strict rule in a controlled way.

The diagram below shows how Java's type hierarchy works for the Number family and how wildcards let you write methods that accept multiple list types at once. Notice that without wildcards, each List<X> type is completely separate from every other List<Y> type, even if X is a subclass of Y.

As you can see, the red X marks indicate that List<Integer> and List<Double> have no subtype relationship with each other, even though Integer and Double are siblings under Number. The wildcard <? extends Number> solves this by creating a flexible type that encompasses all lists whose element type is Number or any of its subclasses.

When the Java compiler encounters a wildcard, it applies specific rules about what operations are allowed. These rules are enforced at compile time — by the time your program runs, the wildcard information has been erased (a process called type erasure). This means wildcards are a purely compile-time mechanism for catching errors early.

Unbounded Wildcard: <?>

When you write List<?>, you are saying "a list of some unknown type." The compiler allows you to read elements from this list as Object (since every type extends Object), but it forbids you from adding anything (except null). This is because the compiler cannot verify that whatever you add is compatible with the unknown actual type.

Upper-Bounded Wildcard: <? extends T>

When you write List<? extends Number>, you're saying "a list of some type that is Number or a subclass of Number." This is more useful than <?> because now you can read elements and treat them as Number objects. You can call methods like .doubleValue() on anything you pull out. However, the same add restriction applies — you still cannot put items into the list because the exact subtype is unknown.

Java supports three kinds of wildcards, though this introductory lesson focuses on the first two. The diagram below gives you a visual map of all three types and when you'd use each one. Think of wildcards as different levels of specificity in a search filter.

The decision guide at the bottom of the diagram introduces a helpful mnemonic that many Java developers use: PECS, which stands for Producer Extends, Consumer Super. If a collection produces data for you to read, use extends. If it consumes data that you write into it, use super. For now, just remember the "extends" half of this rule.

Let's walk through a realistic example. Suppose you want to write a method called sumAll that takes a list of any kind of number — Integer, Double, Float — and returns the sum as a double. Without wildcards, you'd need to write a separate method for each number type. With an upper-bounded wildcard, one method handles them all.

It can be confusing to know when to use wildcards versus a regular generic type parameter versus a raw type. The table below compares these three approaches and highlights the trade-offs of each.

This lesson introduced <?> and <? extends T> as your first steps into wildcard territory. As you continue your Java journey, you'll encounter more powerful generics features that build on these foundations. The table below shows what comes next.

One particularly important advanced concept is the lower-bounded wildcard <? super T>. While <? extends T> makes a collection readable but not writable, <? super T> does the opposite — it makes a collection writable but limits what you can read from it. Together, these two bounded wildcards form the full PECS pattern that professional Java developers rely on daily.