JDK-6959402 : javac fail with nonsensical errors due to cyclical source dependencies
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 6u20
  • Priority: P3
  • Status: Resolved
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2010-06-08
  • Updated: 2013-05-30
  • Resolved: 2013-05-29
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 8
8Resolved
Related Reports
Duplicate :  
Description
J2SE Version (please include all output from java -version flag):
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) Client VM (build 16.3-b01, mixed mode, sharing)

Does this problem occur on J2SE 1.3, 1.4.x or 1.5?  Yes / No (pick one)
Yes. (Happens with javac 1.5.0_13 also.)

Operating System Configuration Information (be specific):
Windows XP Professional SP2

Hardware Configuration Information (be specific):
Intel Pentium 4, 3.2 GHz, 2 GB RAM


Bug Description:

Certain cyclical dependencies between source files cause javac to fail
with nonsensical errors. See "Steps to Reproduce" below for an example.
The bug can also surface when the dependency cycle involves more than
two source files.

Whether the bug is triggered depends on the order in which javac
processes the classes internally. Adding or changing a source file
that has merely an indirect dependency on the classes of the cycle can
also affect this order. This makes the bug particularly insidious, as
it can be triggered by modifications in seemingly unrelated code 


Steps to Reproduce (be specific):

1) In a package "example", create these two source files:

8<--------------------------------------------------------------------

package example;

import example.Bravo.Nested;
import java.io.Serializable;
import java.util.AbstractList;


class Alfa
{
    private static abstract class Error1<T>
        extends AbstractList<T> { }

    private interface Error2
        extends Serializable { }
}

8<--------------------------------------------------------------------

package example;

import static example.Alfa.*;

class Bravo
{
    public interface Nested { }
}

8<--------------------------------------------------------------------

2) Compile with "javac example\Alfa.java example\Bravo.java".
Compilation fails with these errors:

example\Alfa.java:14: cannot find symbol
symbol  : class Serializable
location: class example.Alfa
        extends Serializable { }
                ^
example\Alfa.java:11: cannot find symbol
symbol  : class AbstractList
location: class example.Alfa
        extends AbstractList<T> { }
                ^
example\Alfa.java:11: a generic class may not extend java.lang.Throwable
        extends AbstractList<T> { }
                         ^
3 errors

Specifying the classes in a different order ("javac example\Bravo.java
example\Alfa.java") compiles successfully.

The example above contains unused imports, to make the example minimal.
In real code the imports will be used of course.

The bug can be worked around by explicitly qualifying the respective
class names (Serializable, AbstractList) or by eliminating one of the
imports.

Comments
This is still reproducible in jdk8 b91
29-05-2013

EVALUATION The cyclic import statements are causing javac to go from Alfa to Bravo (because of the import in Alfa) and then back to Alfa (because of the static import in Bravo); this means that Alfa is completed before its import statements have been fully processed.
11-08-2010