JDK-7101822 : Compiling depends on order of imports
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 6u31,7
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: linux_ubuntu,windows_xp
  • CPU: x86
  • Submitted: 2011-10-17
  • Updated: 2017-05-16
  • Resolved: 2014-12-03
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 9
9 b42Fixed
Related Reports
Blocks :  
Blocks :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HosSpot(TM) Server VM (build 21.0-b17, mixed mode))

ADDITIONAL OS VERSION INFORMATION :
Linux Computer 2.6.38-11-generic #50-Ubuntu SMP Mon Sep 12 :21:18_14 UTC 2011 i686 i686 i386 GNU/Linux

A DESCRIPTION OF THE PROBLEM :
In some situations the order of imports in a class may be imported to let javac
compile all classes:

Let X be a class having an inner class X_1 extending some class Y in a
different package. If a subtype of X_1 have to be imported (e.g. it has
another inner class which is referenced) and it is imported before Y is
imported, then X_1 is not compiled.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Create Z.java in package z with content:
{{{
package z;
public class  Z{}
}}}

Create A.java in package a with content:
{{{
package a;
import a.A.B.C;
import z.Z;
public class A {
    class B extends Z {
        class C {}
    }
    class D {
        Class foo()  {
            return C.class;
        }
    }
}
}}}

try to run: javac a/A.java

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
A compiles without problems.
ACTUAL -
A does not compile

ERROR MESSAGES/STACK TRACES THAT OCCUR :
a/A.java:5 error: cannot find symbol
    class B extends Z {
                                  ^
  symbol:   class Z
  location: class A
1 error

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Reorder the imports or do not nest the classes.

Comments
What is the estimated timeline for fixing this bug? Any chance it will be fixed in jdk9? It is something we are continually having to work around in Graal: http://hg.openjdk.java.net/graal/graal/rev/87a40fe1ba0c http://hg.openjdk.java.net/graal/graal/rev/451468f7340b http://hg.openjdk.java.net/graal/graal/rev/af95e5727fdc http://hg.openjdk.java.net/graal/graal/rev/c5449c0d5909 http://hg.openjdk.java.net/graal/graal/rev/e2a14719e833 http://hg.openjdk.java.net/graal/graal/rev/7ce149d349c9
26-08-2014

With all new language features coming into JDK 8, this is too risky to be fixed in this release; changing import logic to be lazy (as opposed to the current problematic eager scheme) is a big change.
30-05-2013

EVALUATION This is related to 7084633. Eager evaluation of import statements causes premature completion of symbol, leading to spurious resolution diagnostics. In this case, the first import statement: import a.A.B.C will trigger completion for this class: class B extends Z Since completion consists in atributing supertypes, javac will attempt at resolving 'Z', which will fail, given that Z has not been imported yet.
18-10-2011