Bug ID: JDK-6695838 javac does not detect cyclic inheritance involving static inner classes after import clause

Versions (Unresolved/Resolved/Fixed)

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 7
7 b34Fixed

I am still fighting with the cyclic inheritance problem and the fact that it gets compiled sometimes and other times it does not. It might be a bug in javac. Can somebody please take a look at this or tell me, whom I can contact for this issue?

For the bug to show, a class and an interface are needed:
sandbox/Foo.java:
<start code>
package sandbox;

class Foo implements Foo$Intf {
   
    public static interface Moo$Intf {}
   
}
<end code>

sandbox/Foo$Intf.java:
<start code>
package sandbox;

import sandbox.Foo.Moo$Intf;

public interface Foo$Intf extends Foo.Moo$Intf {}
<end code>


This is a dependency-cycle and violates therefore JLS 8.1.4. But calling "javac -cp . sandbox/Foo\$Intf.java" is successful. I tried it using the version of javac, which is part of the javafx-repository, jdk 1.6.0_03 and jdk 1.6.0_10.

SUGGESTED FIX A webrev of this fix is available at http://sa.sfbay.sun.com/projects/langtools_data/7/6695838/
08-08-2008
EVALUATION The two class declarations are indeed cyclic; accordingly to JLS 8.1.4 we have that: Foo depends on Foo$Intf (Foo$Intf appears in the implements clause of Foo) Foo$Intf depends on Moo$Intf (Moo$Intf appears in the extends clause of Foo$Intf) Foo$Intf depends on Foo (Foo appears as a qualifier in the extends clause of Foo$Intf) For transitivity, we have that Foo depends on itself; as such the code should be rejected with a compile-time error. This problem is due to the fact that when a toplevel class is completed in memberEnter, completion of import statements is triggered before the toplevel class symbol's UNATTRIBUTED flag is set. The code in Check that is in charge of detecting circularities rely upon the fact that such a flag has been set for all half-entered classes. If an half-entered class is found in the chain of superypes of a given class, this means that a circularity has just been detected (since supertypes' symbols are completed ahead of circularity checks).
24-06-2008
WORK AROUND remove the import statement at in one of the two classes
30-04-2008
SUGGESTED FIX The problem is, that memberEnter for the toplevel, which includes the import-statement, is called before c.flags_field is set to UNATTRIBUTED. Because of that, the cycle is not detected. If the order of the two blocks are changed, the cycle gets detected and compiling the two files fails like it should.
30-04-2008