Ttdfjt

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.