wildcards in generics

[Vishwanath Krishnamurthi]

Hi ranchers,

For this question:

public static <E extends Number> List<? super E> process(List<E> nums)
A programmer wants to use this method like this:
// INSERT DECLARATIONS HERE
output = process(input);
Which pairs of declarations could be placed at // INSERT DECLARATIONS HERE to allow
the code to compile? (Choose all that apply.)

A. ArrayList<Integer> input = null;
ArrayList<Integer> output = null;

B. ArrayList<Integer> input = null;
List<Integer> output = null;

C. ArrayList<Integer> input = null;
List<Number> output = null;

D. List<Number> input = null;
ArrayList<Integer> output = null;

E. List<Number> input = null;
List<Number> output = null;

F. List<Integer> input = null;
List<Integer> output = null;

G. None of the above.

Answer:
B, E, and F are correct.
The return type of process is definitely declared as a List, not an ArrayList, so A and D
are wrong. C is wrong because the return type evaluates to List<Integer>, and that can't
be assigned to a variable of type List<Number>. Of course all these would probably cause a
NullPointerException since the variables are still null�but the question only asked us
to get the code to compile.

can you please tell me how in option c the return type evaluates to List<Integer>?

I can understand that on comparing
process(List<E> nums) with
ArrayList<Integer>

E becomes Integer.

so, the return type becoming List<? super Integer> is also OK..

but how does it evaluate to List<Integer>?

Thanks

[nico dotti]

What's the question number? I remember seeing this and I think it's an errata and the 'List<? super E>' is something else. I believe that would mean that the return type couldn't be type parameratized so you have to have a List without the List<Can'tPutParamaterizedType> Check the question against the errata though 'cause I could be wrong.

[Vishwanath Krishnamurthi]

Thanks Nico.... It was an errata.. and ya the change
<E extends Number> List<E> process(List<E> nums) in the question solves the problem

[nico dotti]

Cool. So for the record when you have a <? super E> it's precarious because since generics is a compile time thing it has no way of knowing which one of the 'super's' it's going to be. Say we replace E with Integer, the compiler doesn't know if ? is going to be an Integer, Number, Object, or what? So your calling reference var would have to be non parameterized type. You'll need to investigate this further to make it 'stick' but just know that this is one of the weird things about generics that you'll be up against come exam time!
[ December 13, 2007: Message edited by: nico dotti ]

[Vishwanath Krishnamurthi]

Thanks Nico, for pointing out that. (Am not sure if everything of that registered...) the compiler would first have to resolve and find out what E is and then check if the type of the passed parameter is consistent with (? extends (resolved-type) )
God!!! Whoever would come up with such situations!!

[nico dotti]

Man! Shame on me! I meant <? super E>...sorry for the confusion! (BTW, I edited it to what I mean <? super E>

So in this case what I said before about it could be an <Integer> <Number> <Object> holds true and the reference variable that will get the returned object can't use type parameter. So if the 'base' class is a List (provided E is replaced with Integer) you could return List <? super E> to List myList but not List<Integer> myList, or List<Number> myList, or List<Object> myList, because the compiler doesn't know which of these it may be. It weird, hard to remember, but that's deal LOL Sorry for the mistake in my last post
[ December 13, 2007: Message edited by: nico dotti ]