Uses of T extends U?

This is handy when you want to return a super type; exactly like you showed in your example.

You take a U as input and return a T - which is a super-type of U; the other way around to declare this would be T super U - but this is not legal in java.

This should be an example of what I mean actually. Suppose a very simple class like:

static class Holder<T> {

    private final T t;

    public Holder(T t) {
        this.t = t;
    }

    public <U super T> U whenNull(U whenNull){
        return t == null ? whenNull : t;
    }
}

Method whenNull as it is defined would not compile, as U super T is not allowed in java.

Instead you could add another type parameter and invert the types:

static class Holder<U, T extends U> {

    private final T t;

    public Holder(T t) {
        this.t = t;
    }

    public U whenNull(U whenNull) {
        return t == null ? whenNull : t;
    }
}

And usage would be:

Holder<Number, Integer> n = new Holder<>(null);
Number num = n.whenNull(22D);

this allows to return a super type; but it looks very weird. We have added another type in the class declaration.

We could resort to:

static class Holder<T> {

    private final T t;

    public Holder(T t) {
        this.t = t;
    }

    public static <U, T extends U> U whenNull(U whenNull, Holder<T> holder) {
        return holder.t == null ? whenNull : holder.t;
    }
}

or even make this method static.

For an existing limitation, you could try to do:

Optional.ofNullable(<SomeSubTypeThatIsNull>)
        .orElse(<SomeSuperType>)

I think that, in fact, this only makes sense when the type parameter of the method appears as the type parameter of a parameterized type that is part of the method signature.

(At least, I couldn't quickly come up with an example where it would really makes sense otherwise)

This is also the case in the question that you linked to, where the method type parameters are used as type parameters in the AutoBean class.

A small update:

Based on the discussion in the question and other answers, the core of this question was likely a misinterpretation of the way of how the type parameters are used. As such, this question could be considered as a duplicate of Meaning of <T, U extends T> in java function declaration , but hopefully someone will consider this answer helpful nevertheless.

In the end, the reason for using the pattern of <T, U extends T> can be seen in the inheritance relationships of parameterized types, which in detail may be fairly complicated. As an example, to illustrate the most relevant point: A List<Integer> is not a subtype of a List<Number>.

An example showing where it can make a difference is below. It contains a "trivial" implementation that always works (and does not make sense, as far as I can tell). But the type bound becomes relevant when the type parameters T and U are also the type parameters of the method parameters and return type. Whith the T extends U, you can return a type that has a supertype as the type parameter. Otherwise, you couldn't, as shown with the example that // Does not work:

import java.util.ArrayList;
import java.util.List;

public class SupertypeMethod {
    public static void main(String[] args) {

        Integer integer = null;
        Number number = null;

        List<Number> numberList = null;
        List<Integer> integerList = null;

        // Always works:
        integer = fooTrivial(integer);
        number = fooTrivial(number);
        number = fooTrivial(integer);

        numberList = withList(numberList);
        //numberList = withList(integerList); // Does not work

        // Both work:
        numberList = withListAndBound(numberList);
        numberList = withListAndBound(integerList);
    }

    public static <T, U extends T> T fooTrivial(U u) {
        return u;
    }

    public static <T, U extends T> List<T> withListAndBound(List<U> u) {
        List<T> result = new ArrayList<T>();
        result.add(u.get(0));
        return result;
    }

    public static <T> List<T> withList(List<T> u) {
        List<T> result = new ArrayList<T>();
        result.add(u.get(0));
        return result;
    }

}

(This looks a bit contrived, of course, but I think that one could imagine scenarios where this actually makes sense)

Tags:

Java

Generics

Recent Posts