Introduction

PECS stands for "Producer Extends, Consumer Super." It is a Java generics guideline for deciding whether a wildcard should use extends or super when working with collections.

The rule is short, but the idea behind it is important. If a structure produces values for you to read, use extends. If it consumes values that you want to put into it, use super.

Producer: ? extends T

Use ? extends T when the collection is a source of T values and you mainly read from it:

1import java.util.List;
2
3public class Demo {
4    public static double sum(List<? extends Number> values) {
5        double total = 0.0;
6        for (Number n : values) {
7            total += n.doubleValue();
8        }
9        return total;
10    }
11}

Why extends? Because List<Integer> and List<Double> should both be acceptable as producers of Number.

The tradeoff is that once you accept List<? extends Number>, you generally should not add new values to it. Java does not know the exact subtype inside the list, only that it extends Number.

Consumer: ? super T

Use ? super T when the collection is a destination for values you want to write:

1import java.util.List;
2
3public class Demo {
4    public static void addDefaults(List<? super Integer> values) {
5        values.add(10);
6        values.add(20);
7    }
8}

This works because a List<Integer>, List<Number>, or List<Object> can all consume Integer values safely.

The tradeoff is on the read side. When you get a value back from List<? super Integer>, the safe type is only Object, because Java does not know the precise element type beyond "some supertype of Integer."

Why PECS Matters

PECS is about balancing flexibility and type safety. Without wildcards, methods become too narrow:

double sum(List<Number> values)

This would reject List<Integer> and List<Double>, even though both are perfectly valid sources of numbers.

Using List<? extends Number> makes the method more useful without sacrificing safety.

A Practical Copy Example

The classic example combines both sides:

1import java.util.List;
2
3public class Demo {
4    public static <T> void copy(List<? super T> dest, List<? extends T> src) {
5        for (T item : src) {
6            dest.add(item);
7        }
8    }
9}

Here:

• 'src is a producer, so it uses extends'
• 'dest is a consumer, so it uses super'

This is PECS in one method signature.

When You Do Not Need a Wildcard

If a parameter is both heavily read from and written to, a wildcard may not be the right tool. Sometimes a plain type parameter is clearer:

1public static <T> void swapFirstTwo(List<T> list) {
2    T first = list.get(0);
3    list.set(0, list.get(1));
4    list.set(1, first);
5}

PECS is most useful when the collection has a one-sided role: mainly producer or mainly consumer.

Common Pitfalls

The biggest mistake is memorizing the acronym without understanding the read-write tradeoff. extends is good for reading, but restrictive for writing. super is good for writing, but restrictive for typed reading.

Another common issue is using List<Number> where List<? extends Number> was intended. That makes the API less flexible than necessary.

Developers also sometimes apply wildcards everywhere even when a plain type parameter would be clearer. PECS is a guideline, not a command to add wildcards to every generic signature.

Finally, remember that generics in Java are invariant. List<Integer> is not a subtype of List<Number>, which is exactly why PECS exists.

Summary

• PECS means "Producer Extends, Consumer Super."
• Use ? extends T when a collection produces values you read.
• Use ? super T when a collection consumes values you add.
• 'extends improves read flexibility, while super improves write flexibility.'
• Use plain type parameters instead of wildcards when the collection needs to be both read from and written to in a balanced way.