FULL PRODUCT VERSION :
java version "1.5.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_01-b08)
Java HotSpot(TM) Client VM (build 1.5.0_01-b08, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
MS Windows 2000 [Version 5.00.2195]

A DESCRIPTION OF THE PROBLEM :
Javac crashes in compiling the test code below.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Create a file Test.java with the source code below. Then run javac Test.java.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
compiled classes
ACTUAL -
javac crash

ERROR MESSAGES/STACK TRACES THAT OCCUR :
An exception has occurred in the compiler (1.5.0_01). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport)  after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report.  Thank you.
java.lang.NullPointerException
        at com.sun.tools.javac.comp.Check.checkCompatibleConcretes(Check.java:1141)
        at com.sun.tools.javac.comp.Check.checkCompatibleSupertypes(Check.java:1495)
        at com.sun.tools.javac.comp.Attr.attribClassBody(Attr.java:2451)
        at com.sun.tools.javac.comp.Attr.attribClass(Attr.java:2406)
        at com.sun.tools.javac.comp.Attr.attribClass(Attr.java:2355)
        at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:444)
        at com.sun.tools.javac.main.Main.compile(Main.java:592)
        at com.sun.tools.javac.main.Main.compile(Main.java:544)
        at com.sun.tools.javac.Main.compile(Main.java:67)
        at com.sun.tools.javac.Main.main(Main.java:52)


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
interface Ac<S extends St<S,A>,A extends Ac<S,A>> { };

interface St<S extends St<S,A>,A extends Ac<S,A>> { };

abstract class CSS<X, Y> implements St<CSS<X, Y>, CSN<X, Y>> {};

final class CSN<X, Y> extends CSS<X, Y> implements Ac<CSS<X, Y>, CSN<X, Y>> {};
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
If class CSN is defined in the file BEFORE class CSS, then the program compiles.
  xxxxx@xxxxx   2005-1-17 17:38:56 GMT

N/A

We should try to fix this in mustang.
This has no compatibility impact and a workaround exists, so
we don't plan to backport this to JDK 5.

The problem appears to be that attribClassBody is called to
soon, specifically checkCompatibleSupertypes.  The fix should
ensure that attribClassBody is called after all classes
have been entered.  While cycles in the inheritance graph are
disallowed, cyclic dependencies can exist anyways as the submitters
example illustrates.

  xxxxx@xxxxx   2005-1-25 01:33:30 GMT

We are considering backporting this to Tiger.

  xxxxx@xxxxx   2005-07-02 20:06:56 GMT
Posted Date : 2005-07-02 20:06:56.0

In response to SDN feedback:

Thank you for bringing this problem to our attention.  I have reopened 6292765.
See also bug 6404691.  Until I have a solution that fixes all these related
issues, I think it is premature to consider a backport to 5.0.
Posted Date : 2006-06-17 23:18:40.0

I can confirm the problem is still there under 1.5.0_02

testing

The evaluation mentions that workaround exists: but the workaround assumes that the two classes/interfaces be defined in the same file.  If both are public, and in separate files, then it can be less feasible when using an IDE, ant, etc. to specify the order files are loaded, and in large projects difficult even to figure out which classes are interacting this way.

As you are considering backporting this fix into Tiger, I strongly encourage you to do so because manual compilation of an entire library to ensure that one class file is compiled in proper order is a very poor workaround for a production system.

Is it even possible to specify that order for javadoc?
I'm getting the same exception in javadoc as I do in
javac, and the workaround I use for javac (which is
just to run the compiler a second time, which happens
to work in my case) doesn't work under javadoc.

I got the same problem (exception) with JDK 1.5.0_05. Fortunately, that error does not occur under eclipse (3.1.*).

We have a large project and it would be nice to have this bug fixed. Otherwise I have to check over 2000 classes, where that bug might occur.

can't wait until b67 comes out - I'm totally stuck in my project just because of this problem (and the workaround does NOT work for me in that particular case...)

The problem still exists in 1.5.0_07 and 1.6 beta2 (build 1.6.0-beta-b59g).

Correction: In the real 1.6 beta 2 (build 1.6.0-beta2-b86), this bug doesn't exist. However, bug 6292765, still exists.

This bug still exists in 1.5.0_10 & 11

And 1.5.0_12.  Unfortunately this bug does indicate which class it failed on. :(