JDK-6663588 : Compiler goes into infinite loop for Cyclic Inheritance test case
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2008-02-15
  • Updated: 2011-05-18
  • Resolved: 2011-05-18
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 b25Fixed
Related Reports
Relates :  
JDK-7079713 - javac hangs when compiling a class that references a cyclically inherited class
Description
Description:
StackOverFlow Error while trying to compile the following Cyclic inheritance test code
If the bound to TypeParameter T is commented, Compiler works fine throwing cyclic inheritance error as expected.
<code>
bash-3.00$ cat Cyclic.java
class Cyclic <T extends Cyclic.Inn> extends Cyclic {

     class Inn extends Cyclic.Inn{

     }
}


</code>
Compilation result is :
<output>
The system is out of resources.
Consult the following stack trace for details.
java.lang.StackOverflowError
        at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:568)
        at com.sun.tools.javac.code.Types$UnaryVisitor.visit(Types.java:3240)
        at com.sun.tools.javac.code.Types.supertype(Types.java:1605)
        at com.sun.tools.javac.comp.Resolve.findMemberType(Resolve.java:889)
        at com.sun.tools.javac.comp.Resolve.findMemberType(Resolve.java:891)
        at com.sun.tools.javac.comp.Resolve.findMemberType(Resolve.java:891)
        at com.sun.tools.javac.comp.Resolve.findMemberType(Resolve.java:891)
        at com.sun.tools.javac.comp.Resolve.findMemberType(Resolve.java:891)
        at com.sun.tools.javac.comp.Resolve.findMemberType(Resolve.java:891)
        at com.sun.tools.javac.comp.Resolve.findMemberType(Resolve.java:891)
        at com.sun.tools.javac.comp.Resolve.findMemberType(Resolve.java:891)
        at com.sun.tools.javac.comp.Resolve.findMemberType(Resolve.java:891)
        at com.sun.tools.javac.comp.Resolve.findMemberType(Resolve.java:891)
        at com.sun.tools.javac.comp.Resolve.findMemberType(Resolve.java:891)
        at com.sun.tools.javac.comp.Resolve.findMemberType(Resolve.java:891)
        at com.sun.tools.javac.comp.Resolve.findMemberType(Resolve.java:891)
        at com.sun.tools.javac.comp.Resolve.findMemberType(Resolve.java:891)


</output>
<version>
/net/sqindia/export/disk09/jdk/7/latest/binaries/solsparc/bin/java -version
java version "1.7.0-ea"
Java(TM) SE Runtime Environment (build 1.7.0-ea-b24)
Java HotSpot(TM) Client VM (build 12.0-b01, mixed mode)

bash-3.00$ uname -a
SunOS hrajan 5.10 Generic sun4u sparc SUNW,Sun-Blade-100
Comments
SUGGESTED FIX http://sa.sfbay.sun.com/projects/langtools_data/7/6663588/
15-02-2008
EVALUATION Type-variable bounds might refer to classes belonging to a cyclic inheritance tree which causes the resolution process to enter a loop when looking up for symbols. In this case, the resolution process hangs in method Resolve.findMemberType() when trying to attribute the declared bound of the type variable Cyclic.T. The resolution process is structured so that the entire inheritance tree (starting from the class in which the symbol is referenced) is browsed until a matching symbol is found. In this case this process never ends since the symbol Cyclic (the bound of Cyclic.T) is searched within the scope of Cyclic itself during the attribution of the bound of Cyclic.T. Since no such symbol is found within the scope of Cyclic, the resolver then tries to find the given symbol inside the scope of the Cyclic' supertype. However, since the supertype of Cyclic happens to be Cyclic itself, this causes the same method to be recusrively invoke with the same arguments. The solution is to detect anomalies in the inheritance trees BEFORE starting the attribution of type variables.
15-02-2008