Bugzilla – Full Text Bug Listing
| Summary: | [1.5][compiler] Bug in the way eclipse handles overriding of generic abstract method by a non-abstract method | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Rémi Forax <forax> | ||||||
| Component: | Core | Assignee: | Srikanth Sankaran <srikanth_sankaran> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | Olivier_Thomann, satyam.kandula, stephan.herrmann | ||||||
| Version: | 3.7 | Flags: | satyam.kandula:
review+
|
||||||
| Target Milestone: | 3.7.1 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
Srikanth, please investigate. javac 1.6 and 1.7 compile this code. See that eclipse compiles this alright:
abstract class C<T> {
public abstract Object foo(T x);
public void bar(T x){
System.out.println(foo(x));
}
}
public class X extends C<String> {
public Integer foo(String x){ return 1; }
public static void main(String args[])
{
new X().bar(null);
}
}
Also this variation:
abstract class B<T> {
public abstract Object foo(T x);
}
abstract class C<T> extends B<T> {
public Object foo(String x){ return 1; }
public void bar(T x){
System.out.println(foo(x));
}
}
public class X extends C<String> {
public static void main(String args[])
{
new X().bar(null);
}
}
Eclipse also silently compiles this code while javac
correctly complains:
abstract class B <T> {
public abstract String foo(T x);
}
abstract class C<T> extends B<T> {
public Object foo(String x){ return 1; }
}
public class X extends C<String> {
}
Created attachment 189088 [details]
Patch under test
Comment on attachment 189088 [details]
Patch under test
This patch fails some cases, back to debug.
This is a little bit more involved than my initial assessment. I'll continue to look at it as time permits, but this may not be before M6. Created attachment 196288 [details]
Patch under consideration
Passes all tests, Satyam, please review - TIA. Srikanth, Code in comment 3 still gets compiled with this patch silenty. Is this being addressed in a different bug? (In reply to comment #10) > Srikanth, > Code in comment 3 still gets compiled with this patch silenty. Is this being > addressed in a different bug? OOps.. sorry! I was using wrong patch! I am getting the error. The patch looks good to me. As this is too late for 3.7, I have released this fix only in BETA_JAVA7 branch. Verified using patch feature 1.0.0-20110623-0900. Just a minor nagging regarding the tests: I was confused by not finding a new *positive* test, although the original issue is about "should compile". Is there a specific rationale behind adding the unresolvable field zork, or is that just a pseudo-random deviation to increase test coverage? (In reply to comment #14) > Is there a specific rationale behind adding the unresolvable field zork, > or is that just a pseudo-random deviation to increase test coverage? No, it is just the result of copy/paste - since the error that is the subject of this bug doesn't show up anymore as verified by the test, it was left at that. |
Build Identifier: I20101028-1441 Section 8.4.8.4 of JLS 3 says (see bullet 1) that the following example should compile but it don't compile. Reproducible: Always Steps to Reproduce: Try to compile that code: abstract class C<T> { public abstract Object foo(T x); public Integer foo(String x){ return 1; } public void bar(T x){ System.out.println(foo(x)); } } class E extends C<String> { public static void main(String args[]) { new E().bar(null); } }