JDK-6372782 : possibly invalid "abstract method not implemented" emitted by compiler
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2006-01-16
  • Updated: 2011-02-16
  • Resolved: 2006-10-02
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.
JDK 6 Other
6u1Resolved OpenJDK6Resolved
Related Reports
Duplicate :  
JDK-6292765 - java.lang.NullPointerException at Check.checkCompatibleConcretes
Description
FULL PRODUCT VERSION :
java version "1.6.0-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-rc-b66)
Java HotSpot(TM) Client VM (build 1.6.0-rc-b66, mixed mode, sharing)
The problem persists as of Mustang b67.

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
A project that utilises Generics considerably fails to compile with errors  of "abstract method not implemented", while it is (hopefully) obvious that they have been implemented by the superclass - NetBeans editor confirms the results:

1) did not emit any errors for the opened file.

2) when the mentioned method is implemented in the class concerned, NB indicates that the implementation is overriding an existing one.

In addition, the @Override in the "workaround" attached does not produce any compiler errors, which is certainly inconsistent with the overall picture here.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
The project is also set up to reproduce the primary problem ("abstract method not implemented"):
1) compile (press F9 in NetBeans) PlainPlanarVector.java and the secondary one (javac exits abnormally):
2) compile PlanarVectorVariable.java respectively.


REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
@Override
public ReturnType problematicMethod() {
    return super.problematicMethod();
}
Comments
EVALUATION This appears to be a problem initializing the supertype of PlainPlanarVector. That type has Type.noType as it's supertype (which shouldn't happen). At this time I'm unable to provide a workaround (I can't compile the program on Tiger) other than rewriting your code to use a little less type variables. While my tentative judgement is that the compiler should be able to compile the program, you code could benefit from less dependency on type variables. Here is a tip that might help you reduce the number of type varibles: When a type variable is only used as return type it is not needed, for example: class Foo<T extends Foo<T>> { T getSelf() { return this; } } class Bar extends Foo<Bar> { Bar getSelf() { return this; } } Can be rewritten to: class Foo { Foo getSelf() { return this; } } class Bar extends Foo { Bar getSelf() { return this; } } Hope this helps.
10-02-2006
EVALUATION Thanks for the additional info. I'm able to reproduce the problem. If I use the -XDdev option to javac I can see that the first command crashes. I will investigate furhter to see what the problem is.
18-01-2006
EVALUATION I hate to say this but I really need a reproducible test case for javac. NetBeans uses ant which is known not to recompile dependencies correctly, so for all I know, this is a problem with ant.
16-01-2006