The compiler accepts the following without complaint:

class outer {
private int i;
static class inner extends outer {
inner() {
i = 1; // should be ambiguous
}
}
}


        class Y {
static class Z {}
        }
        class X {
static class Z {}
                static class nest2 extends Y {
Z z; // should be ambiguous
{ // This one is detected!
// z = new Z();
}
                }
        }

See also 4096022.

william.maddox@Eng 1998-06-10

There is a less contrived case of this problem in the JDK source for TreeMap.
See the attached mail from IBM.

The interface Map.Entry is inherited everywhere, and TreeMap itself has a
local implementation TreeMap.Entry. Some places in the code refer to Entry
using a simple name, even though they are in nested classes which implement Map.

The problem might be that types inherited from interfaces are not considered
as bindings for simple type names.

package java.util;

abstract class TreeMap2 extends AbstractMap implements Map {
    static abstract class Entry implements Map.Entry { }

    abstract class Foo implements Map {
// Following line fails to elicit error, b/c Map.Entry is not considered:
Entry bar = null;
    }

    abstract class Foo2 extends AbstractMap {
// Following line fails to elicit error, b/c Map.Entry is not considered:
Entry bar = null;
    }
}

abstract class Foo3 extends AbstractMap implements Map {
// Following line gets a false error:
// Entry bar = null;
//tm.java:19: Class java.util.Entry not found.

// Following line gets a false error:
// AbstractMap.Entry bar2 = null;
//tm.java:23: Class java.util.AbstractMap. Entry not found.

Map.Entry bar3 = null;
    }

I recommend raising the priority of this bug to 3, since it affects JDK code.

john.rose@Eng 1999-02-22

The example above is illegal for reasons other than stated, as it attempts
to access an uplevel instance variable from within a *static* nested class.
It should read:

class outer {
static private int i; //made field static
static class inner extends outer {
inner() {
i = 1; // should be ambiguous
}
}
}

william.maddox@Eng 1999-08-06