19

According to this entry in the Java Generics FAQ, there are some circumstances where a generic method has no equivalent non-generic method that uses wildcard types. According to that answer,

If a method signature uses multi-level wildcard types then there is always a difference between the generic method signature and the wildcard version of it.

They give the example of a method <T> void print1( List <Box<T>> list), which "requires a list of boxes of the same type." The wildcard version, void print2( List <Box<?>> list), "accepts a heterogenous list of boxes of different types," and thus is not equivalent.

How do you interpret the the differences between the following two method signatures:

 <T extends Iterable<?>> void f(Class<T> x) {} void g(Class<? extends Iterable<?>> x) {}

Intuitively, it seems like these definitions should be equivalent. However, the call f(ArrayList.class) compiles using the first method, but the call g(ArrayList.class) using the second method results in a compile-time error: 

g(java.lang.Class<? extends java.lang.Iterable<?>>) in Test cannot be applied to (java.lang.Class<java.util.ArrayList>)

Interestingly, both functions can be called with each others' arguments, because the following compiles:

class Test { <T extends Iterable<?>> void f(Class<T> x) { g(x); } void g(Class<? extends Iterable<?>> x) { f(x); } }

Using javap -verbose Test, I can see that f() has the generic signature 

<T::Ljava/lang/Iterable<*>;>(Ljava/lang/Class<TT;>;)V;

and g() has the generic signature

(Ljava/lang/Class<+Ljava/lang/Iterable<*>;>;)V;

What explains this behavior? How should I interpret the differences between these methods' signatures?

Improve this question
2
  • +1 for a generics question that doesn't have the answer "you can't do this with generics" for a change. Commented Jul 19, 2012 at 22:30
  • The difference in semantics is understandable, however I find it strange that it doesn't compile. Removing the wildcard on Iterable from g does compile for some reason: void g(Class<? extends Iterable> x). Commented Jul 19, 2012 at 23:04

4 Answers 4

Reset to default
4

Well, going by the spec, neither invocation is legal. But why does the first one type check while the second does not?

The difference is in how the methods are checked for applicability (see §15.12.2 and §15.12.2.2 in particular).

  • For simple, non-generic g to be applicable, the argument Class<ArrayList> would need to be a subtype of Class<? extends Iterable<?>>. That means ? extends Iterable<?> needs to contain ArrayList, written ArrayList <= ? extends Iterable<?>. Rules 4 and 1 can be applied transitively, so that ArrayList needs to be a subtype of Iterable<?>.

    Going by §4.10.2 any parameterization C<...> is a (direct) subtype of the raw type C. So ArrayList<?> is a subtype of ArrayList, but not the other way around. Transitively, ArrayList is not a subtype of Iterable<?>.

    Thus g is not applicable.

  • f is generic, for simplicity let us assume the type argument ArrayList is explicitly specified. To test f for applicability, Class<ArrayList> needs to be a subtype of Class<T> [T=ArrayList] = Class<ArrayList>. Since subtyping is reflexisve, that is true.

    Also for f to be applicable, the type argument needs to be within its bounds. It is not because, as we've shown above, ArrayList is not a subtype of Iterable<?>.

So why does it compile anyways?

It's a bug. Following a bug report and subsequent fix the JDT compiler explicitly rules out the first case (type argument containment). The second case is still happily ignored, because the JDT considers ArrayList to be a subtype of Iterable<?> (TypeBinding.isCompatibleWith(TypeBinding)).

I don't know why javac behaves the same, but I assume for similar reasons. You will notice that javac does not issue an unchecked warning when assigning a raw ArrayList to an Iterable<?> either.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

3

If the type parameter were a wildcard-parameterized type, then the problem does not occur:

Class<ArrayList<?>> foo = null; f(foo); g(foo);

I think this is almost certainly a weird case arising out of the fact that the type of the class literal is Class<ArrayList>, and so the type parameter in this case (ArrayList) is a raw type, and the subtyping relationship between raw ArrayList and wildcard-parameterized ArrayList<?> is complicated.

I haven't read the language specification closely, so I'm not exactly sure why the subtyping works in the explicit type parameter case but not in the wildcard case. It could also very well be a bug.

Improve this answer

3 Comments

+1 It's never been clear to me why the class literals of generic classes are parameterized with raw types instead of wildcarded types.
@PaulBellora: Interestingly, this problem does not occur in Scala, which requires me to parameterize the class literals of generic classes. I can successfully call both methods from Scala with classOf[java.util.ArrayList[_]].
@newacct: This may be a bug. Even though Class<? extends Iterable<?>> isn't assignable from Class<ArrayList>, I can write a method <T extends Iterable<?>> Class<? extends Iterable<?>> convert(Class<T> x) { x } that converts ArrayList.class to Class<? extends Iterable<?>>. The direct assignment Class<? extends Iterable<?>> cls = ArrayList.class; fails but Class<? extends Iterable<?>> cls = convert(ArrayList.class); works, even though convert() performs no casts. This allows me to call g(convert(ArrayList.class)).
0

Guess: The thing representing the first ? (ArrayList) does not 'implement' ArrayList<E> (by virtue of the double nested wildcard). I know this sounds funny but....

Consider (for the original listing):

 void g(Class<? extends Iterable<Object> x) {} // Fail void g(Class<? extends Iterable<?> x) {} // Fail void g(Class<? extends Iterable x) {} // OK

And

// Compiles public class Test{ <T extends Iterable<?>> void f(ArrayList<T> x) {} void g(ArrayList<? extends Iterable<?>> x) {} void d(){ ArrayList<ArrayList<Integer>> d = new ArrayList<ArrayList<Integer>>(); f(d); g(d); } }

This 

// Does not compile on g(d) public class Test{ <T extends Iterable<?>> void f(ArrayList<T> x) {} void g(ArrayList<? extends Iterable<?>> x) {} void d(){ ArrayList<ArrayList> d = new ArrayList<ArrayList>(); f(d); g(d); } }
Improve this answer

2 Comments

In the case of your second example, why does the call to f(d) succeed while the call to g(d) does not compile? Drawing an analogy with the Box class described in the question, is the signature void g(ArrayList<? extends Iterable<?>> x) saying that g() accepts an ArrayList of Iterables (or Iterable subclasses) that are possibly of different types, whereas <T extends Iterable<?>> void f(ArrayList<T> x) accepts an ArrayList of Iterables that are all of the same type? How does this type of reasoning extend to Class<? extends Iterable<?>>, where Class is not a collection?
I don't know, I would assume for the same reason your code doesn't compile. I used ArrayList twice to ensure it wasn't something specific to the Class class. Change that to any parameterized type if you wish, box for example. My point is that it looks like the parameterized type gets wiped out over nested wildcards, similar to what @newacct has mentioned.
0

These are not quite the same:

<T extends Iterable<?>> void f(Class<T> x) {} void g(Class<? extends Iterable<?>> x) {}

The difference is that g accepts a "Class of unknown that implements Iterable of unknown", but ArrayList<T> is constrained implementing Iterable<T>, not Iterable<?>, so it doesn't match.

To make it clearer, g will accept Foo implements Iterable<?>, but not AraryList<T> implements Iterable<T>.

Improve this answer

4 Comments

You're not making sense here. ArrayList<T> implements Iterable<T>.
@PaulBellora Exactly. ArrayList<T> doesn't implement Iterable<?>. Remember that Iterable<T> is not on instance of Iterable<?> as far as generic typing is concerned.
You're still not making sense. Where did the bit about ArrayList implementing Iterable<List> come from? Secondly, Iterable<?> is assignable from any ArrayList<T>.
@PaulBellora Uhhh yeah. I do mean Iterable<T> (edited my answer). But it still stands that ArrayList<T> isn't a match because Iterable<T> isn't Iterable<?> as far as matching the the method signature is concerned - the T is tied to the class, but ITerable<?> is not - see the last sentence of my answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.