Java identifier resolution rules

Question

What search order does the Java compiler use to resolve Foo in the following class?

class Test
{
  Foo f;
}

Empirical tests reveal the following search order:

1. Nested classes
2. Superclass nested classes
3. java.lang.* classes
4. Others?

but I'd like to know where this is discussed in the Java Language Specification.

Answer 1

It should follow the same order than the different scopes presented in the Scope of Local Variable Declarations.

Edit: my link to the JVM specs referred to the execution phase, not the compilation phase, as commented by the OP Gili

Since it is not a complete answer, I leave it here as CW to start the thread.

Answer 2

I don't think that there is a search order in the sense that you mean. Rather, I think that this rule applies:

6.5.5 Meaning of Type Names The meaning of a name classified as a TypeName is determined as follows.

6.5.5.1 Simple Type Names If a type name consists of a single Identifier, then the identifier must occur in the scope of exactly one visible declaration of a type with this name, or a compile-time error occurs. The meaning of the type name is that type.

In this context, imports count as declarations; see JLS 6.1. However, the complicating factor is the Shadowing rules (JLS 6.3.1) which say that some kinds of declarations (of types in this case) hide existing declarations, and others don't. Specifically, an "import on demand" (e.g. import java.util.*; or the implicit import of java.lang.*) do not shadow other declarations.

So for example;

package foo;

import java.sql.Date;
import java.util.*;  // import on demand: java.util.Date does not shadow java.sql.Date
import java.awt.*;  // import on demand: java.awt.List does not shadow java.util.List

class Integer { // (foo.)Integer shadows java.lang.Integer
    ...

    static class Integer { // (foo.Integer.)Integer shadows foo.Integer.
        ...

        List t = ... // Compilation error, because there are currently two visible 
                     // declarations of List (JLS 6.5.5.1)
    }
}

The other wrinkle is that a "single-type-import" (like import java.sql.Date; above) shadows types declared in the same package, and types imported on demand, but it does not shadow other types imported via another "single-type-import" (JLS 6.3.1). So for example, the following is a compilation error:

import java.sql.Date;
import java.util.Date;  // Compilation error