Comments on: Generics Journey Continues

By: Daniel Yokomizo

Daniel Yokomizo — Mon, 17 Dec 2007 20:57:38 +0000

The problem is that your doSomethingReading method is saying to the compiler, I require a MySet of any generic type that is a subtype of Foo. So T can be Foo or SubFoo. If T is SubFoo, it’s obvious to see that it won’t work (i.e. Foo can’t be assigned to SubFoo without casting). To your problem compile you need the super wildcard: boolean contains(T o). With this in place MySet is saying that it can contain Foo or any supertype of i. Not much useful though.

By: Eric Burke

Eric Burke — Mon, 17 Dec 2007 17:59:43 +0000

“uproar” ???

By: Doug

Doug — Mon, 17 Dec 2007 17:55:36 +0000

I’m not sure that I follow what the whole uproar is about. From what I can tell, Kevin Bourrillion got off on a wrong tangent by incorrectly assuming substitutability where there is none. A Set of SubFoo cannot be substituted for a Set of Foo. If it could, then some wiseacre could add an object of type OtherSubFoo to the set.

Arrays are a special case in Java (see JLS3 4.10.3), and you can indeed substitute an array of SubFoo for an array of Foo. This is because the array element type is available to be dynamically verified at runtime. Due to type erasure, no such runtime verification is possible with Java generics.

In Scala, one can designate a type parameter as being covariant to allow this; the Scala compiler will then flag as errors any code that is not compatible with that type being covariant. Java doesn’t have this feature.

By: Eric Burke

Eric Burke — Mon, 17 Dec 2007 13:22:25 +0000

@Bob…that “new Foo() {}” was a mistake on my part. That was some leftover cruft from some experimentation I was doing. Thanks for pointing out that boolean contains(T o); is equivalent…that didn’t really occur to me, but seems obvious now that you state it.

By: Bob Lee

Bob Lee — Mon, 17 Dec 2007 09:37:32 +0000

FWIW, this:

boolean contains(T o);

is equivalent to this:

boolean contains(E o);

i.e. I can already pass in any sub type of E.

“new Foo() {}” effectively creates a new anonymous sub type of Foo which does not extend SubFoo. The compiler can’t let us pass a “new Foo() {}” to a method which expects a SubFoo. Incidentally, it can’t let us pass in a plain old Foo to a method which expects a SubFoo either. The problem is, the compiler doesn’t really know what ? is. It has to play it safe because it doesn’t know whether ? is Foo or SubFoo, and it doesn’t know how the method we’re calling will use that object.

By: Jesse

Jesse — Mon, 17 Dec 2007 04:52:36 +0000

Your example ever-so-slightly changes the contract for the contains() method. This code compiles with Set, but not with MySet. It’s reasonable code in both cases:
MySet collections = …
collections.add(Collections.singletonList(”A”));
Iterable a = Collections.singletonList(”A”);
collections.contains(a);