JDK-2213438 : javac hangs when compiling a class that references a cyclically inherited class
  • Type: Backport
  • Backport of: JDK-7079713
  • Component: tools
  • Sub-Component: javac
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2011-08-26
  • Updated: 2012-02-24
  • Resolved: 2012-02-24
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 JDK 8
6u30Fixed 8 b06Fixed
Comments
SUGGESTED FIX A webrev of this fix is available at the following URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d0257833498e
31-08-2011
EVALUATION How javac handles situation in which classfiles are maliciously modified is not specified by the JLS. In general, the JDK 7 compiler is better and it allows programs to be compiled even in the face of such anomalies. There are still corner cases in which the compiler can crash. I think these can be fixed - it remains to be seen if this is the only place that will be problematic when handling with a circular subclass definition. What I'm saying is that the compiler is not designed to cope with this kind of problems (because they cannot arise in a sourcefile, where such hierarchies are detected and corrected). So we have two options: *) Add a check so that the ClassReader ensures that a loaded class is not circular (i.e. recursively walk all supertypes of E and if one of them is E itself, returns an error). *) Fix all locations in which a circular hierarchy could give raise to infinite loops, etc. Doing the first is probably cleaner, but has bigger impact in terms of compatibility - since javac allows certain sources to be compiled even in the face of badly screwed hierarchies, and people might have started to rely on that. The latter preserves compatibility, but there's a chance we will find ourselves stuck in a situation that we didn't predict in which there's nothing sensible for javac to do.
26-08-2011