>The reasons for the restriction on the parameter T are clear. But
>given that restriction, why the wildcard in the type of coll?
>Suppose we define a method
try http://mindprod.com/jgloss/generics.html#SYNTATICSOUP

Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
Torkel Franzen - 27 Jan 2006 12:00 GMT
> try http://mindprod.com/jgloss/generics.html#SYNTATICSOUP
I don't see any answer to my question.
Roedy Green - 27 Jan 2006 14:39 GMT
>> try http://mindprod.com/jgloss/generics.html#SYNTATICSOUP
>
> I don't see any answer to my question.
try it again. I have added some further explanation on the
implications of what I said there.

Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
Torkel Franzen - 27 Jan 2006 14:48 GMT
> try it again.
An answer exactly to the point has already been given by Jeffrey
Schwab.
> I'm looking at that showcase example of generification (from
> java.util.Collections):
[quoted text clipped - 12 lines]
> any subtype U of T, U is a subtype of Comparable<S> and a
> subtype of S. So what calls go through for min but not for min1?
min1 cannot operate on collections of subtypes of T if the actual type
of T is specified explicitly. E.g., if ActualU is a subclass of
ActualT, the compiler doesn't like min1 in this situation:
ArrayList<ActualU> listOfU = new ArrayList<ActualU>();
SomeClass.<ActualT>min(listOfU);
SomeClass.<ActualT>min1(listOfU); // No good.
Here's a more complete example:
import java.util.*;
class Main {
public static void main(String[] args) {
ArrayList<CU> uList = new ArrayList<CU>( );
/* Compiler rejects min1. */
Min.<CT>min(uList);
Min.<CT>min1(uList);
}
}
class CS implements Comparable<CT> {
public int compareTo(CT ct) {
return 0;
}
}
class CT extends CS { }
class CU extends CT { }
class Min {
public static <T extends Object & Comparable<? super T>>
T min(Collection<? extends T> coll) {
return null;
}
public static <T extends Object & Comparable<? super T>>
T min1(Collection<T> coll) {
return null;
}
}
Torkel Franzen - 27 Jan 2006 13:59 GMT
> min1 cannot operate on collections of subtypes of T if the actual type
> of T is specified explicitly.
You're right, that's a point I overlooked. We need to rely on type
inference for min1 to work.
Thomas Hawtin - 27 Jan 2006 16:51 GMT
>> I'm looking at that showcase example of generification (from
>> java.util.Collections):
[quoted text clipped - 20 lines]
> SomeClass.<ActualT>min(listOfU);
> SomeClass.<ActualT>min1(listOfU); // No good.
That's easy to fix:
SomeClass.<ActualU>min1(listOfU); // Good stuff.
It becomes more difficult where the collection type is using wildcards.
> Here's a more complete example:
>
[quoted text clipped - 5 lines]
>
> ArrayList<CU> uList = new ArrayList<CU>( );
If that was:
List<? extends CU> uList = new ArrayList<CU>( );
> /* Compiler rejects min1. */
> Min.<CT>min(uList);
Fine.
> Min.<CT>min1(uList);
Main.java:11: <T>min1(java.util.Collection<T>) in Min cannot be applied
to <CU>(java.util.ArrayList<capture of ? extends CU>)
CU n = Min.<CU>min1(uList);
^
Oops. Okay, we'll try to change the explicit generic argument:
CU n = Min.<? extends CU>min1(uList);
Main.java:11: illegal start of type
CU n = Min.<? extends CU>min1(uList);
^
Main.java:11: > expected
CU n = Min.<? extends CU>min1(uList);
^
I'm not entirely sure why that isn't legal, but apparently it isn't.
The only thing to do, without the Collections-style declaration, is to
remove the explicit generic argument and rely on the capture as the
first error says (can't do this for constructors, btw).
CU n = Min.min1(uList);
> }
>
[quoted text clipped - 21 lines]
> }
> }
Tom Hawtin

Signature
Unemployed English Java programmer
http://jroller.com/page/tackline/