FULL PRODUCT VERSION :
java version "1.6.0_12"
Java(TM) SE Runtime Environment (build 1.6.0_12-b04)
Java HotSpot(TM) Client VM (build 11.2-b01, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
The JLS third edition, section 6.5.2 states: "If the name to the left of the "." is reclassified as a TypeName, then if the Identifier is the name of a method or field of the type denoted by TypeName, this AmbiguousName is reclassified as an ExpressionName. Otherwise, if the Identifier is the name of a member type of the type denoted by TypeName, this AmbiguousName is reclassified as a TypeName."

I'm not sure why "method name" even appears there. This seems to be a typo in the spec., and the compiler does not follow it. Note that as per bug 6247816, inaccessible fields do not obscure nested classes either. Obviously changing these behaviors at this point could break some existing code. I would suggest that this section be modified to state: ... "then if the Identifier is the name of an accessible field of the type denoted by TypeName", which seems to be the actual behavior (I would like confirmation on that if possible though).

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compile code.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Expect compiler error if spec. is correct.
ACTUAL -
Code compiles without error.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
class A {
   public static class Inner {
      public static int a = 4;
   };
   
    public static void Inner() {
   }
}
 
 
public class NameBug {
   public void test() {
      int x = A.Inner.a;
   }
}

---------- END SOURCE ----------