Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Java identifier resolution rules

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.

like image 708
Gili Avatar asked Jul 23 '26 06:07

Gili


2 Answers

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
like image 75
Stephen C Avatar answered Jul 25 '26 19:07

Stephen C


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.

like image 20
4 revsVonC Avatar answered Jul 25 '26 20:07

4 revsVonC



Donate For Us

If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!