Question

The Generic Methods tutorial has this helpful example:

 public <T extends E> boolean addAll(Collection<T> c); 

However, […] the type parameter T is used only once. The return type
doesn’t depend on the type parameter, nor does any other argument to
the method (in this case, there simply is only one argument). […]
If that is the case, one should use wildcards.

The codebase of the project I am working on has a few methods like this:

public <T extends Something> T getThing();

and (not in the same interface)

public <D> void storeData(int id, D data);

Is there any point in having the method type parameter instead of using the bound (Something above, Object below) directly?

(Note that in the former case, all of the few implementations are annotated with @SuppressWarnings("unchecked") and the point could be to hide this warning from the user of the method, but I am not sure this is a laudable achievement.
In the latter case, some implementations use reflection to store instances of different classes differently, but I do not see how this is facilitated by the type parameter.)

Answer 1

There are five different cases of a type parameter appearing only once to consider.

1) Once in return type position:

1.a) Return type is the type variable

public <T extends Something> T getThing();

This should be a red flag: The caller can arbitrarily choose an expected return type and the callee has no way of knowing the chosen type. In other words the implementation can’t guarantee the returned value will be of the specified return type unless it (a) never returns, (b) always throws an exception or (c) always returns null. In all of these cases the return type happens to be irrelevant altogether.

(Personally I don’t mind methods like these if the code is very “dynamic”. I.e. you’re running the risk of a class cast exception anyway and the method boundary is still early enough for the exception to be raised. A good example is deserialzation. All parties calling the method have to know and understand this though..)

1.b) Type variable is contained in return type, but not the return type itself

Very common and valid. Examples are the various factory methods in guava, like Lists.newArrayList().

2) Once in parameter type position:

2.a) Simple type parameter

public static <E> void shuffle(List<E> list);

Note that the implementation actually needs the type parameter in order to shuffle the elements. Nonetheless, the caller should not have to be bothered with it. You can write an internal helper method that “captures” the wildcard:

public static void shuffle(List<?> list) {
  shuffleWithCapture(list);
}

private static <E> void shuffleWithCapture(List<E> list) {
  // implementation
}

2.b) Type parameter with multiple bounds

public static <T extends Foo & Bar> void foo(T);
public static <E extends Foo & Bar> void foo(List<E>);

Since Java does not allow intersection types anywhere but in type parameter bounds, this is the only way to express these signatures.

2.c) Type parameter bound contains the type parameter variable

public static <T extends Comparable<? super T>> void sort(List<T> list);

To express that the elements of the list must be comparable with each other, one needs a name for their type. There is no way to eliminate such type parameters.