wood burning stoves 2.0*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes S&B 1.5 Chapter 7, question 16 Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "S&B 1.5 Chapter 7, question 16" Watch "S&B 1.5 Chapter 7, question 16" New topic
Author

S&B 1.5 Chapter 7, question 16

David Wooddall-Gainey
Greenhorn

Joined: Dec 13, 2007
Posts: 16
Given method decl as


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

B, E and F are correct.

I do not understand why B is correct but A is not.

Looks like return type and argument must be of the same type, and since ArrayList is a List it should work, as it does in B. I thought as long as they were of the same generic type and List base types, they should work.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18765
    
  40

I do not understand why B is correct but A is not.


An ArrayList *is-a* List. However, A List is not always an ArrayList. With A, the compiler can't tell that the returned List is an ArrayList, and hence, will complain. It will work though, if there was an explicit cast.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
David Wooddall-Gainey
Greenhorn

Joined: Dec 13, 2007
Posts: 16
Thank you.

But I don't understand. A List is not always an ArrayList - that is clear.

"..the compiler can't tell the returned List is an ArrayList." Do you mean process only need return a List, which may or may not be an ArrayList. On the other hand on input we need only make sure we send in a List, and an ArrayList qualifies?

Thank you very mush.
Lakuma Yalamanchili
Greenhorn

Joined: Sep 24, 2008
Posts: 26
A is not right as the returned value is a List, and if you notice we are trying to take the returned List into an ArrayList in this option, which is not allowed by the compiler. ArrayList output = <returned List> - This is not allowed by the compiler!!

B is right as the argument of the method takes a List, this means any subtype value is allowed as well, thus ArrayList can be give to the input and the returned value is a List, which is the type of output!

Hope this clarifies your answer.

In the same question that you quoted, I don't understand why C is not right. If we take the types, ArrayList is the input and List is the ouput which is valid and if we look at the type of the generic, the input takes Integer, so E = Integer and the return type has <? super E> which means anything that is a super of Integer, so Number is valid.
So why is ArrayList<Integer> as the input and List<Number> as the output not the right answer?

The explanation says the output evaluates to List<Integer>, but I would say the output would evaluate to List<any Super class of Integer and Integer itself> so List<Number> would also be right, wouldn't it?


[ September 30, 2008: Message edited by: Lakuma Yalamanchili ]
[ September 30, 2008: Message edited by: Lakuma Yalamanchili ]
Manju Kavi
Ranch Hand

Joined: Sep 25, 2008
Posts: 33
C is wrong because in generics there is no polymorphism.
We always do something like this

SuperClass s=new SubClass(); //here "s" is polymorphic

But in generics you cant do that

SuperClass<Super> s=new Subclass<Sub>();

not even this works

SuperClass<Super> s=new SuperClass<Sub>();

So in generics, type parameters should always match.
So in case of option C, we are trying to do this
List<Number>=List<Integer>;

List<Number>=List<any Super class of Integer and Integer itself>; // wont work
It should be..
List<Number>= List<Number>;
Or
List<Integer>= List< Integer>;
David Wooddall-Gainey
Greenhorn

Joined: Dec 13, 2007
Posts: 16
Lakuma,

The eratta sheet removes the "? super" from the return type. The declaration should read

Venkata Saraswathi
Ranch Hand

Joined: Sep 27, 2008
Posts: 55
Hi,

I hope All the answers given are wrong in the given question.
Because the return type of process method is List<? super E>.
i.e it can be any one in the heirarcy (bottom to top) from E to Object and it's not predictable.

As we know, in generics we can't assign list of subtypes to list of supertypes i.e. like List<Number> l = new ArrayList<Integer> //will not work.

So, unless we specify input as List<? extends Object> the code will not work.

Guess I am right. Please correct me.

--
Venkata.

[ October 02, 2008: Message edited by: Venkata Saraswathi ]
[ October 02, 2008: Message edited by: Venkata Saraswathi ]
Manju Kavi
Ranch Hand

Joined: Sep 25, 2008
Posts: 33
Hi Venkat,
You are wrong because here the return type is <E extends Number>, means anything that extends or subtype of Number!
Venkata Saraswathi
Ranch Hand

Joined: Sep 27, 2008
Posts: 55
Hi Manju,

If you observe clearly Qn. 16/7 of K & B Book, process is a generic method.
So, <E extends Number> is not return type, the return type here is List<? super E>.

--
Venkata.
Manju Kavi
Ranch Hand

Joined: Sep 25, 2008
Posts: 33
Hi Venkat,
I meant according to David's question. And according to Qn. 16/7 of K & B Book, even if we declare input as <? extends Object>, but the method takes only <? extends Number>..?
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: S&B 1.5 Chapter 7, question 16