Compiler should omit ambiguity check for members inherited into an inner class

The inner classes specification requires that an access to a member
by a simple name be flagged as ambiguous when a member of that name
is inherited by an enclosing class which is itself contained within
a class that declares a like-named member. This rule has been dropped
in the current JLS 2e draft, for good reason, and is not likely to
be reinstated. The new behavior is that the member belonging to the
innermost class takes precedence silently, regardless of whether the member
was declared in that class, or inherited from another class.

In Kestrel, however, the ambiguity check was left in place, contrary to
the current specification, in order to avoid a possible compatibility issue.
In previous releases, member interfaces were not inherited. This bug has
now been fixed, meaning that in code compiled under Kestrel, some classes
may contain member interfaces by inheritance that they did not contain
previously. To avoid the possibility that the meaning of an existing
program might silently change due to capture of an existing interface
declaration, the check has been left in as a transitional measure.
Developers whose code might be affected by the new treatment of member
interface inheritance will then be force to explicitly resolve the
ambiguity, assuring that in the future, when we remove the check completely,
that their code will function as intended.

We expect to remove the check in the next feature release following Kestrel.

william.maddox@Eng 2000-03-10