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.

Real-World Example - CRED Analytics Dashboard

A financial app's analytics layer needs to display data from several different reporting sources — transaction counts, reward points, bill amounts, membership tiers — each stored as a different Java type. A shared rendering layer reads and displays any of these reports without caring about the element types. The wildcard lets utility methods in the rendering layer accept all report containers without duplicating code per type.

Output:
=== CRED Analytics Dashboard ===

+-----------------------------------------+
| Recent Transactions                     |
+-----------------------------------------+
|   1. HDFC CC Bill - Rs.4200             |
|   2. Zepto - Rs.849                     |
|   3. Swiggy - Rs.412                    |
+-----------------------------------------+

+-----------------------------------------+
| Reward Points (Last 3 Months)           |
+-----------------------------------------+
|   1. 2450 pts                           |
|   2. 1890 pts                           |
|   3. 3100 pts                           |
+-----------------------------------------+

+-----------------------------------------+
| Upcoming Bills                          |
+-----------------------------------------+
|   1. 4200.0 Rs.                         |
|   2. 1500.0 Rs.                         |
|   3. 800.0 Rs.                          |
+-----------------------------------------+

+-----------------------------------------+
| Membership Status                       |
+-----------------------------------------+
|   1. CRED Black                         |
|   2. Travel Benefits Active             |
|   3. Lounge Access: 4 remaining         |
+-----------------------------------------+

+-----------------------------------------+
| Investment Nudges                       |
+-----------------------------------------+
|  (no data)                              |
+-----------------------------------------+

=== Dashboard summary ===
Has empty section : true
Total data points : 10

ReportSection stores items as List<?> because at the point where sections are created, the rendering layer should not need to know the element type — it only renders. renderSection() accepts any ReportSection and reads items through toString() (via string concatenation) — it never adds elements, never creates elements, never needs to call type-specific methods. hasEmptySection() and totalDataPoints() access only structural properties. Every operation on the wildcard list is read-only and structural, which is exactly the scope where ? belongs.

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