Hcfyk

Lately I encountered a method defined similar to this and I don't exactly understand its usage:

public static <T, U extends T> T foo(U u) { ... }

A sample use could be like this:

// Baz is just the containing class of foo()

Number n = Baz.foo(1);

Where T is inferred to Number and U (probably) to Integer. But I can't wrap my head around when this is superior to e.g. this method definition:

public static <T> T bar(T t) { ... }

If I call it like this:

Number n = Baz.bar(2);

The code still works. T is inferred to either Number or Integer (Don't know if the argument type, in this example Integer is preferred over the call site return type Number)

I've read these questions: 1, 2 but I still don't know if the first method with 2 parameters has any advantage over the second method with only one generic.

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)

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>)

The first method

public static <T, U extends T> T foo(U u) { ... }

means that T and U can be different types. I.e. one type T and one type U that is a sub-type of T.

With your second example

public static <T> T bar(T t) { ... }

bar(T t) must return the same type as argument t is. It can not return an object of a type that is a super-class to the argument type. That would only be possible with your first variant.