Community
Participate
Working Groups
I am running the latest stable release of Eclipse on Windows XP with a 1.3 compliant compiler, running using JDK1.3.1_07. Eclipse did not complain about two classes that inherited from an abstract class but did not implement the abstract methods. It happily compiled these classes. An external build file I have that builds and releases the code base complains correctly. Doing a 'Rebuild All' or even clearing the classes from the local directory and refreshin, does not fix the problem.
Please provide a testcase demonstrating our bug, and build number. Also note that one only needs to implement visible abstract methods. Did other compilers behave differently ? Please reopen this defect once required information is available.
Build 200303272130. The compiler with JDK1.3.1_07 complains and the Java Language specification seems to back it up. Have noticed that it only happens when the originating method is in a library class, the example uses the SAX framework DefaultHandler to demonstrate. I tried uploading a test.zip but bugzilla did not like it. The following three classes demonstrate the problem, they use SAX. package test.xml; import org.xml.sax.helpers.DefaultHandler; public abstract class ClassA extends DefaultHandler { } package test.xml; import org.xml.sax.Attributes; import org.xml.sax.SAXException; public abstract class ClassB extends ClassA { public abstract void startElement(String uri, String localName, String qName, Attributes attributes) throws SAXException; public abstract void endElement(String uri, String localName, String qName) throws SAXException; } package test.xml; import org.xml.sax.Attributes; public class ClassC extends ClassB { public ClassC() { } public void endElement(String name) { } public void startElement(String name, Attributes attributes) { } }
Suspecting we are too "lazy" with binary abstract methods.
This issue has been there since day 1. The problem is that the interface org.xml.sax.ContentHandler defines the abstract method endElement(String, String, String). Then the concrete class DefaultHandler implements it, followed by the abstract class ClassB which redefines the method again as an abstract method... why? Who knows. When verifying the type ClassC, we collect the 3 inherited implementations to verify & find a concrete implementation so we don't complain that the abstract method is not implemented. Philippe: Should we complain about the 'missing' concrete method in ClassC OR the abstract method in ClassB which is overriding an inherited concrete method OR nothing, since there is an inherited concrete method?
Sorry I was mistaken, we don't collect the 3 implementations. We only pick up the abstract method from ClassB & the abstract method from the interface ContentHandler. The bug was in how decided if the method from ClassB had a visible implementation.
Simpler test case: public class X extends Y { // should complain missing implementation of foo() } abstract class Y extends Z { public abstract void foo(); } abstract class Z extends T { } class T implements I { public void foo(){} } interface I { public void foo (); } Added regression test LookupTest#test29
Verified.
