JLS 6.3 goes to pains to define the scope of a class, interface, or field "declared" by an import declaration. 6.4.1 explains how shadowing works. Then the rest of Chapter 6 can rely on "in scope" to determine what declaration a variable or type name refers to.

Typically, this is handled by checking for an entity "in scope at the point at which the Identifier occurs" (6.5.4.1, 6.5.5.1, 6.5.6.1).

For some reason, 6.5.2 handles imports separately, as if the concept of an imported declaration being "in scope" were not defined.

Specifically:

~~~
- If the Identifier appears within the scope (��6.3) of a local variable declaration (��14.4) or parameter declaration (��8.4.1, ��8.8.1, ��14.20) or field declaration (��8.3) with that name, then the AmbiguousName is reclassified as an ExpressionName.

- Otherwise, if a field of that name is declared in the compilation unit (��7.3) containing the Identifier by a single-static-import declaration (��7.5.3), or by a static-import-on-demand declaration (��7.5.4) then the AmbiguousName is reclassified as an ExpressionName.
~~~

This could be simplified with:

~~~
- If the Identifier appears within the scope (6.3) of a declaration denoting either a local variable, a formal parameter, or a field with that name, then the AmbiguousName is reclassified as an ExpressionName.
~~~

Similarly, this:

~~~
- Otherwise, if the Identifier is a valid TypeIdentifier and appears within the scope (��6.3) of a top level class (��8 (Classes)) or interface type declaration (��9 (Interfaces)), a local class declaration (��14.3) or member type declaration (��8.5, ��9.5) with that name, then the AmbiguousName is reclassified as a TypeName.

- Otherwise, if the Identifier is a valid TypeIdentifier and a type of that name is declared in the compilation unit (��7.3) containing the Identifier, either by a single-type-import declaration (��7.5.1), or by a type-import-on-demand declaration (��7.5.2), or by a single-static-import declaration (��7.5.3), or by a static-import-on-demand declaration (��7.5.4), then the AmbiguousName is reclassified as a TypeName.
~~~

could be simplified to:

~~~
Otherwise, if the Identifier is a valid TypeIdentifier and appears within the scope (��6.3) of a declaration denoting a class, interface, or type parameter with that name, hen the AmbiguousName is reclassified as a TypeName.
~~~

Note that this adds type parameters, which were incorrectly left out of the old rules. (JEP 395 also addresses this failure to mention type parameters.)