Java Wildcards (?)

Java Wildcards (?)

The wildcard ? in Java generics represents an unknown type. Where a type parameter <T> names the unknown so it can be referred to multiple times, the wildcard ? says "some type, but I neither know nor need to name it." List<?> means "a list of some type of element — I do not know what type, and I am not going to commit to one." This might sound less useful than naming the type, but it solves a specific problem that named type parameters cannot: expressing that a method should accept a collection of any element type when the method does not need to put anything back in or create elements of that type.

What Is a Wildcard?

The wildcard ? is a type argument — it appears where a type argument goes, inside angle brackets — but unlike a named type parameter T, it cannot be referenced by name anywhere else in the same declaration. It has three forms:

UNBOUNDED WILDCARD:
  List<?>            "a list of some unknown type"
  Collection<?>      "a collection of some unknown type"
  Class<?>           "a Class object for some unknown type"

  Can read from it: every element comes out as Object
  Cannot add to it: the compiler rejects any add() call
                    (except null, which is always safe)

UPPER-BOUNDED WILDCARD:
  List<? extends Number>   "a list of some type that is Number or a subtype"
  (covered in the Upper-Bounded Wildcards article)

LOWER-BOUNDED WILDCARD:
  List<? super Integer>    "a list of some type that is Integer or a supertype"
  (covered in the Lower-Bounded Wildcards article)

THIS ARTICLE FOCUSES ON THE UNBOUNDED WILDCARD: List<?>

Basic Overview - Four Things to Understand About the Unbounded Wildcard

1. WHY ? EXISTS: THE INVARIANCE PROBLEM

   Fresher view  : you might expect that because Integer extends Number,
                   a List<Integer> should be usable where a List<Number>
                   is expected. It is NOT. Generic types are invariant -
                   List<Integer> and List<Number> are unrelated types.
                   List<?> solves this: it says "a list of ANY type",
                   and a List<Integer>, List<Number>, or List<String>
                   can all be passed where List<?> is expected.

   Deeper view   : the invariance rule exists because allowing
                   List<Integer> where List<Number> is expected would
                   let you add a Double (a Number) to what is actually
                   a List<Integer>, corrupting it silently. List<?> is
                   safe because it disables BOTH reading with a type
                   AND writing - elements come out as Object, and
                   nothing (except null) can go in.

2. WHAT YOU CAN DO WITH List<?>

   Fresher view  : you can iterate over it, call size(), call isEmpty(),
                   call contains(), pass it to methods that accept
                   List<?>, and read every element as Object.
                   You CANNOT call add(anything except null) on it.

   Deeper view   : the restriction on add() is not a runtime limitation -
                   it is a compile-time check. The compiler refuses
                   add(item) on List<?> because it cannot verify that
                   item is the correct type for the unknown element type.
                   Even if you know the list contains Strings, you cannot
                   add a String through a List<?> reference - the type
                   information has been deliberately erased from the
                   reference's perspective.

3. List<?> vs List<Object>

   Fresher view  : they look similar but behave very differently.
                   List<Object> means the list holds Object values -
                   you can add anything to it (everything is an Object).
                   List<?> means the list holds SOME unknown type -
                   you cannot add anything (you do not know what type
                   is accepted).

   Deeper view   : List<Object> accepts ONLY List<Object> - not
                   List<String>, not List<Integer>. This is generic
                   invariance at work. List<?> accepts List<String>,
                   List<Integer>, List<Object>, and any other
                   parameterized List. This is why a utility method
                   that only reads a list should declare List<?>,
                   not List<Object> - the former accepts any list,
                   the latter accepts almost none.

4. ? vs T - WHEN TO USE WHICH

   Fresher view  : use T when you need to REFER to the type again
                   in the same declaration - in the return type,
                   in another parameter, or inside the body.
                   Use ? when you do not need to name the type at
                   all - the method only reads elements as Object,
                   or only checks size/emptiness.

   Deeper view   : ? is syntactic sugar for a bounded or unbounded
                   type variable that has been "thrown away" -
                   you cannot say "give me back a T" because you
                   never captured T. If you need to do anything
                   with the element beyond treating it as Object,
                   you need a named type parameter instead.

The Invariance Problem That Wildcards Solve

Generic types in Java are invariant: List<String> and List<Integer> are completely unrelated types, even though String and Integer both extend Object. This surprises many developers who expect the relationship between element types to carry into the parameterized type.

Output:
=== printAll(List<?>) - accepts any List ===
  Wireless Mouse
  Laptop Stand
  USB Hub
  ---
  120
  45
  200
  ---
  799.0
  1299.0
  499.0

=== The List<Object> approach fails at compile time ===
  A String
  42

=== What you CAN do with List<?> ===
size()    : 3
isEmpty() : false
contains  : true
get(0)    : Swiggy
add(null) : succeeded (null is always safe)

Common Uses of the Unbounded Wildcard

Utility Methods That Only Read

Any method that only needs to read elements from a collection — printing, counting, searching, logging — should accept List<?> (or Collection<?>) rather than List<Object>. The wildcard makes the method genuinely generic: it works with any parameterized collection, not just List<Object>.

Output:
=== countNonNull ===
cities non-null: 3
rates non-null : 3

=== summarize ===
List[size=3, first=Mumbai, last=Bengaluru]
List[size=3, first=400001, last=560001]
Empty list

=== sameSizeAs ===
cities and codes same size? true
cities and rates same size? false

=== printMap with Map<String, Integer> ===
  Wireless Mouse -> 120
  Laptop Stand -> 45
  USB Hub -> 200
=== printMap with Map<Integer, String> ===
  1 -> Mumbai
  2 -> Pune
  3 -> Nashik

Class<?> - The Most Common Non-List Wildcard

Outside collections, Class<?> is the wildcard you encounter most often. Reflection methods like getDeclaredMethods(), forName(), and annotation reading return or accept Class<?> because the actual class type is unknown at compile time.

Output:
=== describeClass with InventoryService ===
Class     : InventoryService
Package   :
Interface?: false
Methods   : 3
  -> updateStock (2 params)
  -> getStock (1 params)
  -> reconcileInternal (0 params)

=== describeClass with String (from the JDK) ===
Class     : String
Is final  : true

=== createInstance ===
Created  : StringBuilder
Instance :

When to Choose ? Over a Named Type Parameter

The decision between ? and <T> is about whether the type needs to be named and reused. If the method only reads elements (treating each as Object) and never references the type anywhere else, ? is the cleaner choice. The moment the type needs to appear in more than one place in the same declaration, a named parameter becomes necessary.

USE ? WHEN:

  The type appears in exactly ONE position and is never referenced again:

  static void print(List<?> items) { ... }
  // ? appears once - perfect use case

  The method only checks structural properties (size, isEmpty):
  static boolean hasThreePlus(Collection<?> c) { return c.size() >= 3; }

  The method receives a Class<?> for reflection work:
  static void inspect(Class<?> clazz) { ... }

  A field stores a generic container of unknown type:
  private List<?> snapshot;  // the type was lost at some API boundary

USE <T> WHEN:

  The type must appear in TWO or more positions - as a parameter AND
  as the return type, or in two parameters that must match:

  static <T> T getFirst(List<T> items)         // T appears twice
  static <T> List<T> copy(List<T> source)      // T appears twice
  static <T> void swap(T[] arr, int i, int j)  // T appears twice
  static <T> boolean contains(List<T> list, T target) // T appears twice

  The body needs to call T-specific methods or create T instances:
  static <T extends Comparable<T>> T max(T a, T b) {
      return a.compareTo(b) >= 0 ? a : b; // compareTo needs <T extends Comparable<T>>
  }

Wildcard Capture - How the Compiler Works With ?

When you pass a List<?> to a helper method that uses a named type parameter, the compiler performs wildcard capture — it treats the ? as a specific (but unknown) type for the duration of that call. This allows a private helper method to work with the unknown type in a way the public method with ? cannot.

Output:
Before reverse: [Mumbai, Pune, Nashik, Aurangabad]
After reverse : [Aurangabad, Nashik, Pune, Mumbai]

Before swap: [500, 1200, 800, 3000]
After swap : [3000, 1200, 800, 500]

Wildcard capture is what lets algorithms that need a named type variable work behind a ?-based public API. reverse(List<?> list) is the clean public signature — callers can pass any list. reverseHelper(List<T> list) is where the actual mutation happens using the named type. The compiler connects the two by treating the ? captured from the first as the T in the second.

Basic Example

A single printAll method that accepts a list of any element type, using the unbounded wildcard List<?>.

Output

Mumbai
Delhi
400001
110001

How it works:

1. ›List<?> means "a list of some unknown type," so printAll accepts List<String>, List<Integer>, or any other parameterized list.
2. ›Each element read from a List<?> comes out as Object, which is enough since printAll only prints it.
3. ›Nothing can be added to a List<?> (except null) because the compiler cannot verify what type the unknown list actually holds — this is why the wildcard is safe for read-only methods.

Wildcard vs Type Parameter - Side by Side

Best Practices

Use Collection<?> instead of List<?> when the method does not care about ordering or index access. A method that only counts or prints elements should accept Collection<?> rather than List<?> — it is a broader, more flexible type that still prevents mutation of the element type.

Prefer ? over <T> for method parameters when the type is genuinely not needed. A printAll(List<?> items) is clearer in intent than <T> void printAll(List<T> items) — the wildcard version explicitly signals "I do not use the element type for anything meaningful." When a reviewer reads List<?>, they immediately know the method is read-only with respect to the element type.

Do not confuse List<?> with List<Object>. List<Object> accepts only an actual List<Object> — almost nothing in a typed codebase is List<Object>. List<?> accepts any parameterized list. When writing a utility method that should work with any list, List<?> is almost always the right signature.

Reserve wildcard capture (the public-? / private-<T> pattern) for algorithms that must mutate the list. If the method only reads, the public List<?> signature needs no private helper. The helper pattern is specifically for cases like reverse and swap where elements must be re-inserted — operations that require naming the unknown type internally.

Common Mistakes

Mistake 1 - Trying to Add Elements to a List<?>

Mistake 2 - Using List