Generic return types

[Piotr Trochim]

Howdy y'all!

Let me get straight to the point:

    
import java.util.*;
 
public class Example  {
 
    public static void main(String [] args) {
 
        List<Integer> input = null;
        List<Integer> output = null;
        output = f(input);                  // ERROR
    }

    public static <E extends Number> List<? super E> f(List<E> input) {
        List<E> l = null;
        return l;
    }
}

Tried to compile on java 1.5.11 and got the following error message:

Type mismatch: cannot convert from List<capture-of ? super Number> to List<Number>

But wait - the fun's only about to begin

Change the types of both output and input reference variables to List<Number> - You'll get the same stuff.
Change output to List<Number> and input to List<Integer> - same stuff.

TYhe problem is in the return type.

Let's analyse that:
1.) E is any type that passes IS-A test for being a Number.
Both Number and Integer play along, so if we're either passing a list of Numbers or a list of Integers as a method's param - it's OK.

2.) The return type is something that is a supertype to the type we passed.

So if I passed a list of Integers, I would expect to be able to assign the returned reference to the reference types: List<Object>, List<Number> or List <Integer>.
If I was to pass a list of Numbers, I would expect the compiler would let me assign the returned value to the reference types: List<Object> and List<Number>.


But instead - I get that weird looking error message. I checked the same with 'extends' frame - same thing.

Does it mean that I can't specify 'fuzzy' generic return types - only the solid ones?

I'm looking forth to Your feedback.

Cheers,
Paksas

[Cor Takken]

Paksas,

See what happens if you change the return type to List<? super Number>.

<? extends Number> gives the compiler a bit of a moving target (since E is not fixed) and my guess is that the compiler is not able to determine what the procedure will be returning.

I am still trying to get to grips with with generics, so my oppinion is not something that can be relied on yet, but my guess now is that wildcards in the returntype is generally not a good idea. What you are basically saying is that you're not quite sure what you will be doing in this method: "I'm not sure what I'll be returning but it will definetely be an Object or a Number...."

Thanks, you made me look in the Generics chapter again..

Cor

(scheduled for certification coming Friday)

[Piotr Trochim]

I already did that - same thing.

Like I said - it looks like the compiler doesn't handle 'fuzzy' return types well - of any type.

The question is why?

What inspired me to check this case was a mock question from the SCJP 1.5 prep book - the answer to the question clearly points that such thing should be possible - I checked - none of the answers the book marks as correct works !!!

Now how am I going to explain that on an exam?

Best,
Paksas

[Barry Gaunt]

See K & B Errata

620....bug.......Q-16: method declaration s/b:
& 634
public static <E extends Number> List<E> process(List<E> nums)

[ June 11, 2007: Message edited by: Barry Gaunt ]

[Cor Takken]

OK, I read the K&B and on page 596, somewhere halfway (or at least on the CD-version) it says:

"Keep in mind that the wildcards can be used only for reference declarations (including arguments, variables, return types, and so on)."

So it clearly states that wildcards cannot be used on return types, and for the certifications the K&B-book is leading for me.

and hopefully they didn't lie...

Cor

[edit] and now I am going to eat my words... it says it CAN be used for return types.. ..back to the reading class...
[ June 11, 2007: Message edited by: Cor Takken ]

[Cor Takken]

Well... I am not sure whether I am going to spoil things by saying this, but I guess not (if I did: appologies and the bartender is free to tell me off).

I tried some coding and did fool around a bit:

List<Integer>=new List<? extends Number>();

which fails (as it should do according to the book) but shows IMHO exactly what Piotr is trying to do implicitly by specifying the return type of method as he does.

As to why someone would define the returntype of a method as specified beats me, however Piotr has a point especially if the K&B specifies that wildcards are allowed in returntypes. I feel that the book lacks in the wildcard-explanation department a bit especially because the materials tends to grow very fuzzy very fast.

Cor

[edit] now I see that Barry has more or less confirmed my findings in an edit... phew... I was affraid I was loosing it...[/edit]
[ June 11, 2007: Message edited by: Cor Takken ]

[Sergio Tridente]

Piotr,

I already tried to answer in your other thread. Please, take a look and tell me if it is clear now. I'll try to explain again if necessary.

[Piotr Trochim]

Hi

Yes - it's all clear now.

Thank You all for Your help

Best,
Paksas