In guava, why is just "T" used where "? super T" would be possible?

Question

Why do the utility factory methods often use a specific generic parameter (like T) instead of a bounded wildcard parameter (like ? super T)?

For instance, the signature of Functions#forPredicate is:

public static <T> Function<T, Boolean> forPredicate(Predicate<T> predicate)

Why not use:

public static <T> Function<T, Boolean> forPredicate(Predicate<? super T> predicate)

Which would make something like the following possible?

Predicate<Number> isPositivePredicate = ...
Function<Integer, Boolean> isPositiveInteger = Functions.forPredicate(isPositivePredicate);
// above line is compiler error:
//   Type mismatch: cannot convert from Function<Number,Boolean> to Function<Integer,Boolean>

Is it because consumers of Function and Predicate are expected to have the necessary bounded wildcard parameters to make this unnecessary? For example, the generic bounds on Iterables#find would allow a Predicate<Number> to be used on a Iterable<Integer>:

public static <T> T find(Iterable<T> iterable,
                         Predicate<? super T> predicate)

Are there other reasons?

Answer 1

Yes, it's absolutely accurate that we expect the consumers to have the right bounded wildcard parameters, but a couple additional reasons spring to mind:

• In general, we don't widen the types of generic methods until we have a specific reason to. This policy has paid off several times.
• Java's type inference isn't always up to figuring out more advanced generics automatically, so keeping the narrower generics reduces the number of users who need to explicitly specify T.

Answer 2

In the find() example, T can always be inferred unambiguously.

In the forPredicate[1]() example, T can also be inferred unambiguously.

In the forPredicate[2]() example, there's uncertainty what T should be. If the result of the method is assigned to a target type, T can be determined from the target type. Otherwise it's a little head scratching:

forPredicate(isPositive).apply(42);  // T is a subtype of Number, but which one?

In java5/6, it shouldn't compile. (well I tested it on java 6 and it does compile, but it's probably a bug, since java 6 also compiles forPredicate(p).apply("str"))

Java 7 improved a little bit, and the new rule happens to dictate that T=Number. It works, but it feels more like an arbitration for the sake of it.

---

Ideally, we shouldn't need to worry about wildcards. If I need a predicate for my integers, I should declare a Predicate<Integer> parameter. The fact that a Predicate<Number> argument would also be acceptable is another story. It should be the compiler's job to convert Predicate<Number> to Predicate<Integer> - we can do it without overhauling existing java generics type system, a new conversion rule is all that's needed. One can also provide a conversion library

Predicate<Number>  pn = ...;
Predicate<Integer> pi = convert(pn);

Iterable<Integer> iter1 = ...;
Iterable<Number>  iter2 = convert(iter1);

All convert() methods can be generated mechanically.

---

Java 8 make things a little easier. We still cannot do

Predicate<Number>  pn = n -> n.intValue()>0;
Predicate<Integer> pi = pn;  // error!

but we can do

Predicate<Integer> pi = pn::test;  // ok
// it means        pi = (Integer i)->pn.test(i)

also

Function<Integer, Boolean> f = pn::test;   // ok

which is equivalent to f = forPredicate[2](pn). In java 8 we'll rarely need forPredicate() etc to convert between functional types.