6.5.2 Reclassification of Contextually Ambiguous Names

An AmbiguousName is then reclassified as follows:

• If the AmbiguousName is a simple name, consisting of a single Identifier:
  • If the Identifier appears within the scope (§6.3) of a local variable declaration (§14.3) or parameter declaration (§8.4.1, §8.6.1, §14.18) with that name, then the AmbiguousName is reclassified as an ExpressionName.
  • Otherwise, consider the class or interface C within whose declaration the Identifier occurs. If C has one or more fields with that name, which may be either declared within it or inherited, then the AmbiguousName is reclassified as an ExpressionName.
  • Otherwise, if 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 class or interface type declaration (§7.6), then the AmbiguousName is reclassified as a TypeName.
  • Otherwise, if a type of that name is declared in another compilation unit (§7.3) of the package (§7.1) of the compilation unit containing the Identifier, then the AmbiguousName is reclassified as a TypeName.
  • Otherwise, if a type of that name is declared by exactly one type-import-on-demand declaration (§7.5.2) of the compilation unit containing the Identifier, then the AmbiguousName is reclassified as a TypeName.
  • Otherwise, if a type of that name is declared by more than one type-import-on-demand declaration of the compilation unit containing the Identifier, then a compile-time error results.
  • Otherwise, the AmbiguousName is reclassified as a PackageName. A later step determines whether or not a package of that name actually exists.
• If the AmbiguousName is a qualified name, consisting of a name, a ".", and an Identifier, then the name to the left of the "." is first reclassified, for it is itself an AmbiguousName. There is then a choice:
  • If the name to the left of the "." is reclassified as a PackageName, then there is a further choice:
    • If there is a package whose name is the name to the left of the "." and that package contains a declaration of a type whose name is the same as the Identifier, then this AmbiguousName is reclassified as a TypeName.
    • Otherwise, this AmbiguousName is reclassified as a PackageName. A later step determines whether or not a package of that name actually exists.
  • If the name to the left of the "." is reclassified as a TypeName, then this AmbiguousName is reclassified as an ExpressionName. u If the name to the left of the "." is reclassified as an ExpressionName, then this AmbiguousName is reclassified as an ExpressionName.

As an example, consider the following contrived "library code":

package ORG.rpgpoet;


import java.util.Random;

interface Music { Random[] wizards = new Random[4]; }

and then consider this example code in another package:

package bazola;

class Gabriel {
	static int n = ORG.rpgpoet.Music.wizards.length;
}

First of all, the name ORG.rpgpoet.Music.wizards.length is classified as an ExpressionName because it functions as a PostfixExpression. Therefore, each of the names:

ORG.rpgpoet.Music.wizards
ORG.rpgpoet.Music
ORG.rpgpoet
ORG

is initially classified as an AmbiguousName. These are then reclassified:

• Assuming that there is no class or interface named ORG in any other compilation unit of package bazola, then the simple name ORG is reclassified as a PackageName.
• Next, assuming that there is no class or interface named rpgpoet in any compilation unit of package ORG (and we know that there is no such class or interface because package ORG has a subpackage named rpgpoet), the qualified name ORG.rpgpoet is reclassified as a PackageName.
• Next, because package ORG.rpgpoet has an interface type named Music, the qualified name ORG.rpgpoet.Music is reclassified as a TypeName.
• Finally, because the name ORG.rpgpoet.Music is a TypeName, the qualified name ORG.rpgpoet.Music.wizards is reclassified as an ExpressionName.