JDK-6709709 : javadoc does not get compilation errors after type erasure
  • Type: Bug
  • Component: tools
  • Sub-Component: javadoc(tool)
  • Affected Version: 5.0
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2008-06-02
  • Updated: 2013-09-12
  • Resolved: 2011-10-11
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 Availability Release.

To download the current JDK release, click here.
Other Other JDK 6 JDK 7
5.0u16-revFixed 5.0u17Fixed 6u30 b08Fixed 7Resolved
Related Reports
Relates :  
JDK-6908806 - JDK 1.5.0 Update 17 javac fails to compile java code using generics
Relates :  
JDK-7111601 - javac/api/DiagnosticTest/DiagnosticTest03 fails with java.lang.Exception: Stack trace
Relates :  
JDK-7098750 - JCK-compiler: compilation of 32 tests did not fail as expected
Description
FULL PRODUCT VERSION :
java 1.5.0.12

A DESCRIPTION OF THE PROBLEM :
run javadoc against the following class:
package bug;

import java.util.List;

public class JavaDocGenerics {
 public  void a(List<String> s){}
 public  void a(List<StringBuffer> s){}
}

No warning or error will be reported. The html will be generated, although anchors for both methods will be the same.

However,

Run the javadoc against the following class

package bug;



public class JavaDocNoneGenerics {
   public void b(int a){}
   public void b(int a){}
}

The javadoc will report:
" b(int) is already defined in bug.JavaDocGenerics
   public void b(int a){}
               ^
"
and the html file will be generated will one method in it.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
run javadoc against the following class:
package bug;

import java.util.List;

public class JavaDocGenerics {
 public  void a(List<String> s){}
 public  void a(List<StringBuffer> s){}
}

No warning or error will be reported. The html will be generated, although anchors for both methods will be the same.

However,

Run the javadoc against the following class

package bug;



public class JavaDocNoneGenerics {
   public void b(int a){}
   public void b(int a){}
}

The javadoc will report:
" b(int) is already defined in bug.JavaDocGenerics
   public void b(int a){}
               ^
"
and the html file will be generated will one method in it.


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------

package bug;
import java.util.List;

public class JavaDocGenerics {
 public  void a(List<String> s){}
 public  void a(List<StringBuffer> s){}
}





package bug;

public class JavaDocNoneGenerics {
   public void b(int a){}
   public void b(int a){}
}

---------- END SOURCE ----------
Comments
EVALUATION Change in file Check.java. Putting one condition to check for method signature. void duplicateErasureError(int pos, Symbol sym1, Symbol sym2) { if (!sym1.type.isErroneous() && !sym2.type.isErroneous()) { log.error(pos, "name.clash.same.erasure", sym1, sym2); } } ----------------------------------- Comment by Maurizio I approve this fix, as I think that it's good to move error checking earlier in the compiler pipeline. But I must warn you that the fix, as it is now is incomplete, in the sense that there is a very similar test case that, if I'm right, is not covered by your fix; here's the code: import java.util.List; class JavaDocGenerics { public void a(String[] s){} public void a(String... s){} } If you run javadoc on this source, again javadoc fails to detect this error (you cannot have two methods one accepting a varargs and the other one accepting an array - it's a duplicate error, more or less for the same reason for which it's an error to accept two methods with the same erasure in the same class). I know that this testcase is not directly related to CR 6709709 and, perhaps, it is outside the scope of this escalation. It's up to you whether to keep the fix as it is now, or to go for a different one that tackles also the varargs issue. Should you go for the latter option, I'd be happy to help, as we already have that fixed in JDK 7. Maurizio ---------- Some more cases suspected by Maurizio: E.g. another example of thing that might fail with javadoc: class A<X extends Number> { void m(X o) {} } class B extends A<Integer> { void m(Integer o) {} //ok overrides m(X), where X is Integer void m(Number o) {} //error, m(Number) does not override m(X) in A, but have the same erasure }
19-08-2008