Community
Participate
Working Groups
I have a rather unusual class hierarchy somewhat represented by the interface and two classes from below. Eclipse 3.2RC4 reports an error, while 3.1.2 doesn't, and the code compiles and works just fine. ========== AnInterface.java package bug_report; public interface AnInterface { void aMethod(Object anObject, String aString, Object... args); void aMethod(Object anObject, Object... args); } ========== AnAbstractClass.java package bug_report; public abstract class AnAbstractClass implements AnInterface { public void aMethod(Object anObject, Object... args) { System.out.println("AnAbstractClass.aMethod(...)"); } public void aMethod(Object anObject, String aString, Object... args) { System.out.println("AnAbstractClass.aMethod(...)"); } } ========== AnAbstractClass.java package bug_report; public class ASubClass extends AnAbstractClass { @Override public void aMethod(Object anObject, String aString, Object... args) { // // Eclipse 3.2RC4 Reports: Cannot directly invoke the abstract method aMethod(Object, String, Object...) for the type AnInterface // super.aMethod(anObject, aString, this, args); } @Override public void aMethod(Object anObject, Object... args) { super.aMethod(anObject, args); } }
Reproduced with RC4. Works fine with either JDK1.5.0_07 or JDK60b82.
Given it is a regression, we may consider for 3.2RC5 if we have a good fix. This remains a corner situation, and could rather qualify for 3.2.1.
Created attachment 41463 [details] Patch Only need to choose the interface method if its a better match than the concrete method. This is the second case in findMethod() when we're faced with the same issue.
+1 for 3.2RC5. Current behavior is a regression over 3.1, introduced in 3.2RC2. Fix looks good, one omission of a code pattern. Martin - pls cast your vote
Dani - pls cast your vote.
Looked at the patch and talked to Philippe about the potential risk. Approving for 3.2 RC5 since it is a regression and rejects valid code.
Re: comment 6 1) Is this really a critical stop ship defect? It is a recent regression we introduced by mistake, and we have a good/simple fix for it (broken since RC2). We reject valid code. It was discovered in about 2 weeks... 2) What is the potential risk for existing (3.2) clients that now use/rely on Since we reject valid code, there is no impact on existing clients which are broken if they see it.
Mike - pls cast your vote
I don't have enough context to be able to verify the code, but it seems like something that would be good to fix. +1
Added VarargsTest #49 and released into HEAD for RC5
Darin - would you vote for this bug ? (cannot find Martin any longer)
+1 for 3.2RC5
+1
Verified with I20060519-0010 for 3.2RC5
