JDK-6182950 : methods clash algorithm should not depend on return type
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 5.0,6u21
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp,windows_vista
  • CPU: x86
  • Submitted: 2004-10-21
  • Updated: 2017-05-16
  • Resolved: 2011-10-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availabitlity Release.

To download the current JDK release, click here.
JDK 7
7 b55Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :

Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
Following code should not compile:
class x {
    int f(List<String> l) {return 0;}
    double f(List<Integer> l) {return 0;}
}

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Following code should not compile:
class x {
    int f(List<String> l) {return 0;}
    double f(List<Integer> l) {return 0;}
}

since both method have the same erasure.
JLS3 draft 8.4.8.3 says, it is error if there are two methods m1 and m2 in a class such that:
- m1 and m2 have the same name
- m2 is accessible
- the signature of m1 is not subsignature if m2
- both methods have same erasure

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
    Error:  line (4) name clash: f(java.util.List<java.lang.String>) and f(java.util.List<java.lang.Integer>) have the same erasure

 
ACTUAL -
no error

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.util.List;
class x {
    int f(List<String> l) {return 0;}
    double f(List<Integer> l) {return 0;}
}
---------- END SOURCE ----------
###@###.### 10/21/04 23:19 GMT

Comments
SUGGESTED FIX A webrev of this fix is available at the following URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/5caa6c45936a
2009-03-26

EVALUATION Another potential problem: class x { int f(List<String> l) {return 0;} } class y extends x { double f(List<Integer> l) {return 0;} } This program should be rejected according to 8.4.8.3 - there's no overriding between the two versions of f - currently javac allows this wrong overriding.
2009-01-05

EVALUATION The submitter is right. Class x is not well-formed because the method signatures have the same erasure. Return type is not part of a signature, even though a return type should be erased at the same time as a signature (see 6730568). For the record, given: class x { int f(List<String> l) {return 0;} double f(List<Integer> l) {return 0;} } - f(List<String>) is not the same signature as f(List<Integer>). - Then, f(List<String>) is not a subsignature of f(List<Integer>), because f(List<String>) does not have the same signature as f(List<Integer>) nor is f(List<String>) the same as the erasure of f(List<Integer>). - Similarly, f(List<Integer>) is not a subsignature of f(List<String>). - Thus they are not override-equivalent, which makes sense because you would never want to override f(List<Integer>) with f(List<String>). - By 8.4.8.3, a compile-time error should occur because: - both methods have the same name - both are trivially accessible from x - the signature of f(List<String>) is not a subsignature of f(List<Integer>) (or vice-versa) - f(List<String>) has the same erasure as f(List<Integer>) 8.4.8.3 should be clarified to say: "***the signature of*** m1 or some other method...has the same erasure as ***the signature of m2*** or some other method...".
2006-10-26