When to use generic methods and when to use wild-card?

Consider following example from The Java Programming by James Gosling 4th edition below where we want to merge 2 SinglyLinkQueue:

public static <T1, T2 extends T1> void merge(SinglyLinkQueue<T1> d, SinglyLinkQueue<T2> s){ // merge s element into d } public static <T> void merge(SinglyLinkQueue<T> d, SinglyLinkQueue<? extends T> s){ // merge s element into d } 

Both of the above methods have the same functionality. So which is preferable? Answer is 2nd one. In the author's own words :

"The general rule is to use wildcards when you can because code with wildcards is generally more readable than code with multiple type parameters. When deciding if you need a type variable, ask yourself if that type variable is used to relate two or more parameters, or to relate a parameter type with the return type. If the answer is no, then a wildcard should suffice."

Note: In book only second method is given and type parameter name is S instead of 'T'. First method is not there in the book.

In your first question: It means that if there is a relation between the parameter's type and the method's return type then use a generic.

For example:

public <T> T giveMeMaximum(Collection<T> items); public <T> Collection<T> applyFilter(Collection<T> items); 

Here you are extracting some of the T following a certain criteria. If T is Long your methods will return Long and Collection<Long>; the actual return type is dependent on the parameter type, thus it is useful, and advised, to use generic types.

When this is not the case you can use wild card types:

public int count(Collection<?> items); public boolean containsDuplicate(Collection<?> items); 

In this two example whatever the type of the items in the collections the return types will be int and boolean.

In your examples:

interface Collection<E> { public boolean containsAll(Collection<?> c); public boolean addAll(Collection<? extends E> c); } 

those two functions will return a boolean whatever is the types of the items in the collections. In the second case it is limited to instances of a subclass of E.

Second question:

class Collections { public static <T> void copy(List<T> dest, List<? extends T> src) { ... } 

This first code allow you to pass an heterogeneous List<? extends T> src as a parameter. This list can contain multiple elements of different classes as long as they all extends the base class T.

if you had:

interface Fruit{} 

and

class Apple implements Fruit{} class Pear implements Fruit{} class Tomato implements Fruit{} 

you could do

List<? extends Fruit> basket = new ArrayList<? extends Fruit>(); basket.add(new Apple()); basket.add(new Pear()); basket.add(new Tomato()); List<Fruit> fridge = new ArrayList<Fruit>(); Collections.copy(fridge, basket);// works 

On the other hand

class Collections { public static <T, S extends T> void copy(List<T> dest, List<S> src) { ... } 

constrain List<S> src to be of one particular class S that is a subclass of T. The list can only contain elements of one class (in this instance S) and no other class, even if they implement T too. You wouldn't be able to use my previous example but you could do:

List<Apple> basket = new ArrayList<Apple>(); basket.add(new Apple()); basket.add(new Apple()); basket.add(new Apple()); List<Fruit> fridge = new ArrayList<Fruit>(); Collections.copy(fridge, basket); /* works since the basket is defined as a List of apples and not a list of some fruits. */ 

Wildcard method is also generic - you could call it with some range of types.

The <T> syntax defines a type variable name. If a type variable has any use (e.g. in method implementation or as a constraint for other type), then it makes sense to name it, otherwise you could use ?, as anonymous variable. So, looks like just a short-cut.

Moreover, the ? syntax is not avoidable when you declare a field:

class NumberContainer { Set<? extends Number> numbers; } 

I will try and answer your question, one by one.

Don't we think wild card like (Collection<? extends E> c); is also supporting kind of polymorphism?

No. The reason is that the bounded wildcard has no defined parameter type. It is an unknown. All it "knows" is that the "containment" is of a type E (whatever defined). So, it cannot verify and justify whether the value provided matches the bounded type.

So, it's no sensible to have polymorphic behaviours on wildcards.

The document discourages the second declaration and promotes usage of first syntax? What's the difference between the first and second declaration? Both seems to be doing the same thing?

The first option is better in this case as T is always bounded, and source will definitely have values (of unknowns) that subclasses T.

So, suppose that you want to copy all list of numbers, the first option will be

Collections.copy(List<Number> dest, List<? extends Number> src); 

src, essentially, can accept List<Double>, List<Float>, etc. as there is an upper bound to the parameterized type found in dest.

The 2nd option will force you to bind S for every type you want to copy, like so

//For double Collections.copy(List<Number> dest, List<Double> src); //Double extends Number. //For int Collections.copy(List<Number> dest, List<Integer> src); //Integer extends Number. 

As S is a parameterized type that needs binding.

I hope this helps.

? means unknown

The general rule applies: You can read from it, but not write

given simple pojo Car

class Car { void display(){ } } 

This will compile

private static <T extends Car> void addExtractedAgain1(List<T> cars) { T t = cars.get(1); t.display(); cars.add(t); } 

This method won't compile

private static void addExtractedAgain2(List<? extends Car> cars) { Car car = cars.get(1); car.display(); cars.add(car); // will not compile } 

Another example

List<?> hi = Arrays.asList("Hi", new Exception(), 0); hi.forEach(o -> { o.toString() // it's ok to call Object methods and methods that don't need the contained type }); hi.add(...) // nothing can be add here won't compile, we need to tell compiler what the data type is but we do not know 

One other difference which is not listed here.

static <T> void fromArrayToCollection(T[] a, Collection<T> c) { for (T o : a) { c.add(o); // correct } } 

But the following will result in compile time error.

static <T> void fromArrayToCollection(T[] a, Collection<?> c) { for (T o : a) { c.add(o); // compile time error } } 

As far as I understand, there is only one use case when wildcard is strictly needed (i.e. can express something that you can not express using explicit type parameters). This is when you need to specify a lower bound.

Apart from that however wildcards serve to write more concise code, as described by the following statements in the document you mention:

Generic methods allow type parameters to be used to express dependencies among the types of one or more arguments to a method and/or its return type. If there isn't such a dependency, a generic method should not be used.

[...]

Using wildcards is clearer and more concise than declaring explicit type parameters, and should therefore be preferred whenever possible.

[...]

Wildcards also have the advantage that they can be used outside of method signatures, as the types of fields, local variables and arrays.

Mainly -> Wildcards enforce generics at the parameter/argument level of a Non-Generic method. Note. It can also be performed in genericMethod by default, but here instead of ? we can use T itself.

package generics;

public class DemoWildCard { public static void main(String[] args) { DemoWildCard obj = new DemoWildCard(); obj.display(new Person<Integer>()); obj.display(new Person<String>()); } void display(Person<?> person) { //allows person of Integer,String or anything //This cannnot be done if we use T, because in that case we have to make this method itself generic System.out.println(person); } } class Person<T>{ } 

SO wildcard has its specific usecases like this.