When to use generic methods and when to use wild-card?

java

type-parameters

wildcards

generics

byAlex Kataev·Mar 12, 2025

Choose generic methods when you require exact types for operations. They're the primary tool for creating universally useful utilities that also keep track of specific types. Here's an illustrative snippet:

<E> void swap(List<E> list, int i, int j) {
    E temp = list.get(i);
    // Ah, good old switching method. Reminds me of switching seats in a boring lecture.
    list.set(i, list.get(j));
    list.set(j, temp);
}

Opt for wildcards when you need the most flexibility within methods that extract from or contribute to collections. They are perfect when you care less about the concern of specific types. Take a peek at the code below:

void printCollection(Collection<?> c) {
    // Output mode engaged, brace yourselves!
    c.forEach(System.out::println);
}

Generics enforce type integrity while wildcards accommodate broader type ranges.

Differentiate: Type parameters and Wildcards

Type parameters and wildcards in Java are not substitutes for each other - they possess distinct functionalities:

Type parameters are your buddy when you need to maintain relationships between various method arguments. Example: Comparing two items of the same type.
Wildcards step in when operations do not depend on having the same type for every method call.

I highly recommend the Java Generics FAQs by Angelika Langer for a more profound understanding.

Enforcing the type relationships

Type parameters let you create connections where arguments share the same generic type:

public <T> boolean areEqual(T first, T second) {
    // Ready for a face-off!
    return first.equals(second);
}

Attempting the above with wildcards would dribble out, as they cannot ensure identical parameterized types across different arguments.

With bounds come bindings

Wildcards come handy both with upper and lower bounds:

Upper bounded (<? extends T>): Useful for reading operations from subclasses of T.
Lower bounded (<? super T>): Ideal for write operations to superclasses of T.

On the contrary, type parameters can only work with upper bounds but they do accept multiple bounds:

public <T extends Number & Comparable<T>> T min(T a, T b) {
    // Smallest number - a challenge of minuscule proportions!
    return a.compareTo(b) < 0 ? a : b;
}

Leveraging polymorphism

Embrace generic methods when polymorphic behavior with bounded types is the need of the hour. These methods readily morph based on the input they receive.

Merging types with wildcards

For marrying multiple types without getting entangled in multiple type parameters, wildcards make a fine choice. They simplify your code by maintaining readability and effectively constraining types:

public void addNumbersToCollection(Collection<? super Number> collection) {
    // Adding some numbers, because we care about the sum of all things!
    collection.add(1);
    collection.add(1.0);
    collection.add(1L);
}

Syncing precision with adaptability

Go with <T> when the type variable plays a specific role, often in the method implementation or as a constraint for another type variable:

public <T extends Comparable<T>> T max(Collection<T> collection) {
    // Who is the tallest among us all!
}

Choose wildcards when the type variable doesn’t play a key role and you want the maximum flexibility:

public void consume(Collection<?> collection) {
    // All things allowed, so dig in everyone!
}

In-depth: best practices and scenarios

Uniform operations

For methods that welcome a collection of a single type and output a result of the same type, generic methods reign supreme:

public <T> List<T> duplicateList(List<T> original) {
    // Whoops! My hand slipped and created a replica.
    return new ArrayList<>(original);
}

Handling heterogeneous collections

When the hurdle is handling heterogeneous collections but with constraints, generics bring the solution to treat elements uniformly while maintaining type safety:

public <T extends Number> void processNumbers(List<T> numbers) {
    // Let's rumble, numbers!
}

Return type intricacies

In cases where the return type hinges on the type of the method arguments, generic methods should be your top preference:

public <T> T getFirstElement(List<T> list) {
    // Hi there, first comers! Your prize awaits.
    return list.get(0);
}

Collection operations with constraints

For operations where constraining a collection to a single subclass is essential, wildcards are most suited:

public void processIntegerList(List<? extends Integer> list) {
    // Here comes the Integer train, hop on!
}

Interchanging between collections

Here's how to use bounded wildcards to switch between collections of different subtypes:

public <T> void copyCollection(List<? extends T> src, List<? super T> dst) {
    // Switcheroo time, hold tight!
    dst.addAll(src);
}

explain-codes / Java / When to use generic methods and when to use wild-card?

Linked

Java Generics With a Class & Interface - Together



Get type of a generic parameter in Java with reflection



Is there a javadoc tag for documenting generic type parameters?



What is the difference between ? and Object in Java generics?



Mockito: List Matchers with generics



How to use Class<T> in Java?



How to do method overloading for null argument?



Differentiate: Type parameters and Wildcards Enforcing the type relationships With bounds come bindings Leveraging polymorphism Merging types with wildcards Syncing precision with adaptability In-depth: best practices and scenarios