Declaring <T extends Number> constrains the type parameter so the method body can call any Number member like doubleValue(). Without the bound, T would be Object and you would not be able to do arithmetic on it. The single bound is the common case; multiple bounds are written <T extends Number & Comparable<T>> (only the first may be a class). Use this when the method genuinely needs to call a method on T; if it only stores or returns the value, a wildcard is usually a better fit (next accordion).

PECS stands for "Producer Extends, Consumer Super". A list you READ from (a producer of T) should be List<? extends T>, and a list you WRITE to (a consumer of T) should be List<? super T>. The asymmetry exists because Java generics are invariant by default: List<Integer> is NOT a subtype of List<Number>. Wildcards relax the rule for one direction at a time. Apply PECS to any method signature that takes two collections of related types; the extra typing pays back in caller flexibility.

<T> introduces a generic parameter; List<? extends T> lets callers pass List<Integer> when T = Number; Comparator<? super T> lets a comparator declared for a supertype be reused. This is exactly how Collections.max is signed in the standard library. The pattern keeps the API maximally permissive without losing type safety: a Comparator<Number> can sort List<Integer> because every Integer IS a Number. When in doubt, copy the standard library's signatures: they have been refined over decades.