views:

278

answers:

5

As you can see, having a non void return type is important.

class TestValid {

public String f(List<String> list) {
    return null;
}

public Integer f(List<Integer> list) {
    return null;
}

public void test() {
    f(Arrays.asList("asdf"));
    f(Arrays.asList(123));
}

}

class TestInvalid {

public void f(List<String> list) {
    System.out.println("strings");
}

public void f(List<Integer> list) {
    System.out.println("numbers");
}

}
A: 

After the type erasure part of compilation, List<String> and List<Integer> are both really type List; in TestInvalid you are making two methods with the same runtime signature.

Jason S
+1  A: 

In the second case, the methods f cannot be distinguished at runtime due to type-erasure.

http://java.sun.com/docs/books/tutorial/java/generics/erasure.html

Thus they both have precisely the same signature.

FarmBoy
+6  A: 

TestValid isn't valid to start with:

TestValid.java:9: name clash: f(List<Integer>) and f(List<String>)
have the same erasure
public Integer f(List<Integer> list) {
               ^

So the return type is a red herring. If return types were taken into account in determining signatures for overloading, then it would be valid, but currently it's as invalid as this:

// Equally invalid
public Integer f() {}
public String f() {}

If you genuinely managed to get TestValid to compile, I'd be interested to know which compiler you're using.

Jon Skeet
Fun fact: if you do manage to create `TestValid` (using a non-standard compiler, ASM byte code engineering, or whatever), a standard Java compiler will link to the correct method based on the generic type parameter.
erickson
@erickson: Isn't the generic parameter erased at the bytecode level? Could you elaborate?
aioobe
@aioobe - the signature of the methods after type erasure is the same, and that's why a stock compiler rightly rejects them. But, there is information about the type parameters left in the class. You can find this out via reflection, and it's what the compiler uses to tell you that you can't pass a `List<Integer>` to a (compiled and erased) method that takes a `List<String>`. In the hack I described, however, I think the compiler is actually looking at the return type.
erickson
Yes basic theory says it should not work.It compiles and run fine with eclipse 3.5 but dont compile with eclipse 3.6.
lacroix1547
The return type is not a red herring - it's the reason the compiler is (incorrectly) accepting it. While return types are not used for overload resolution, the methods are not overload equivalent, due to having different pre-erasure types.
Matthew Wightman
@Jon see http://stackoverflow.com/questions/3110014/is-this-valid-java for a list of compilers that accept TestValid. You'll be surprised by the amount of compilers that allow it.
Andrei Fierbinteanu
@Andrei: Yes, that's definitely surprising. Weird.
Jon Skeet
A: 

For TestValid class: the functions appear to be overloaded. You wont get a compile time error if the caller passes a parameter List object which is type defined.eg: new ArrayList() or new ArrayList(). as the signature (return type and input parameters) after type erasure is not same. However you will get compile time error if the you pass in new ArrayList().

The second definition violates the basic principle of overloading a function where two functions with same signature (return type and input parameters) after type erasure.

frictionlesspulley
A: 

TestValid have been debated at another question

lacroix1547