Java Generics - 这两个方法声明是等价的吗？

Question

Given some class SomeBaseClass , are these two method declarations equivalent?

public <T extends SomeBaseClass> void myMethod(Class<T> clz)

and

public void myMethod(Class<? extends SomeBaseClass> clz)

Answer 1

For the caller: yes, they are equivalent.

For the code inside the method: no.

The difference is that within the code of the first example you can use the type T (for example to hold an object created by clz.newInstance() ), while in the second you can't.

Answer 2

No, they're not. With the first definition, you can use the type T inside the method definition, eg create an ArrayList<T> or return T. With the second definition, that's not possible.

Answer 3

Bounded wildcards are subject to certain restrictions to avoid heap pollution.

When you use the wildcard ? extends X you know you can read generic information, but you cannot write.

For instance

List<String> jedis = new ArrayList<String>();
jedis.add("Obiwan");

List<? extends CharSequence> ls = jedis
CharSequence obiwan = ls.get(0); //Ok
ls.add(new StringBuffer("Anakin")); //Not Ok

The compiler avoided heap pollution when you tried to add a CharSequence (ie StringBuffer) to the collection. Because the compiler cannot be sure (due to wildcards) that the actual implementation of the collection is of type StringBuffer.

When you use ? super X you know you can write generic information, but you cannot be sure of the type of what you read.

For instance

List<Object> jedis = new ArrayList<Object>();
jedis.add("Obiwan"); 

List<? super String> ls = jedis;
ls.add("Anakin"); //Ok
String obiwan = ls.get(0); //Not Ok, we can´t be sure list is of Strings.

In this case, due to wildcards, the compiler knows that the actual implementation of the collection could be anything in the ancestors of String. Thus it cannot guarantee that what you will get will be a String. Right?

This same restrictions are the ones you would be subject too in any declaration with bounded wildcards. These are typically known as the get/put principle.

By using a type parameter T you change the story, from the method standpoint you are not using a bounded wildcard but an actual type and therefore you could "get" and "put" things into instances of the class and the compiler would not complain.

For instance, consider the code in Collections.sort method. If we write a method as follows, we would get a compile error:

public static void sort(List<? extends Number> numbers){
    Object[] a = numbers.toArray();
    Arrays.sort(a);
    ListIterator<? extends Number> i = numbers.listIterator();
    for (int j=0; j<a.length; j++) {
        i.next();
        i.set((Number)a[j]); //Not Ok, you cannot be sure the list is of Number
    }
}

But if you write it like this, you can do the work

public static <T extends Number> void sort(List<T> numbers){
    Object[] a = numbers.toArray();
    Arrays.sort(a);
    ListIterator<T> i = numbers.listIterator();
    for (int j=0; j<a.length; j++) {
        i.next();
        i.set((T)a[j]);
    }
}

And you could even invoke the method with collections bounded with wildcards thanks to a thing called capture conversion:

List<? extends Number> ints = new ArrayList<Integer>();
List<? extends Number> floats = new ArrayList<Float>();
sort(ints);
sort(floats);

This could not be achieved otherwise.

In summary, as others said from the caller standpoint they are alike, from the implementation standpoint, they are not.

Answer 4

No. On top of my head, I can think of the following differences:

1. The two versions are not override-equivalent. For instance,

    class Foo { public <T extends SomeBaseClass> void myMethod(Class<T> clz) { } } class Bar extends Foo { public void myMethod(Class<? extends SomeBaseClass> clz) { } } 

   does not compile:

   Name clash: The method myMethod(Class) of type Bar has the same erasure as myMethod(Class) of type Foo but does not override it

2. If a type parameter appears more than once in a method signature, it always represents the same type, but if a wildcard appears more than once, each occurrence may refer to a different type. For instance,

    <T extends Comparable<T>> T max(T a, T b) { return a.compareTo(b) > 0 ? a : b; } 

   compiles, but

    Comparable<?> max(Comparable<?> a, Comparable<?> b) { return a.compareTo(b) > 0 ? a : b; } 

   does not, because the latter may be called by

    max(Integer.MAX_VALUE, "hello"); 

3. The method body may refer to the actual type used by the caller using a type parameter, but not using a wildcard type. For instance:

    <T extends Comparable<T>> T max(T... ts) { if (ts.length == 0) { return null; } T max = ts[0]; for (int i = 1; i < ts.length; i++) { if (max.compareTo(ts[i]) > 0) { max = ts[i]; } } return max; } 

   compiles.

Answer 5

@Mark @Joachim @Michael

see the example in JLS3 5.1.10 Capture Conversion

public static void reverse(List<?> list) { rev(list);}
private static <T> void rev(List<T> list){ ... }

so the <?> version can do anything the <T> version can do.

this is easy to accept if the runtime is reified. a List<?> object must be a List<X> object of some specific non-wildcard X anyway, and we can access this X at runtime. So there's no difference using a List<?> or a List<T>

With type erasure, we have no access to T or X , so there's no difference either. We can insert a T into a List<T> - but where can you get a T object, if T is private to the invocation, and erased? There are two possibilities:

1. the T object is already stored in the List<T> . so we are manipulating elements themselves. As the reverse/rev example shows, there's no problem doing this to List<?> either

2. it comes out-of-band . There's other arrangement made by the programmer, so that an object somewhere else is guaranteed to be of type T for the invocation. Unchecked casting must be done to override compiler. Again, no problem to do the same thing to List<?>