Whenever a reference to an inner type of the kind A.B is found, javac needs to normalize the qualifier type A, so that any reference to potentially parameterized types are made explicit. This normalization occurs regardless of whether this type is explicitly provided in the source code, or inferred from the enclosing context.

There are two crucial methods in javac that perform a traversal on a sequence of types trying to find a subclass of a given symbol sym. If found, then that type is returned. Those methods are asOuterSuper and asEnclosingSuper.

They differ on which types are being considered for examination during that sequence; the sequence is not built eagerly but delegated to another call.

- asOuterSuper delegates to getEnclosingType: since for methods and field access we need to look up only on enclosing instances
- asEnclosingSuper delegates to the enclClass: the qualifier is computed by the current class (lexically enclosing classes) and contrary to expressions, we can refer to a type even if there is no enclosing instance, for types we can look everywhere on the path.

That leads to the two different use-cases of these two methods:

- If there is type qualifier, and qualifier is implicit, asEnclosingSuper is used in visitTypeApply and checkIdInternal.
- If there is a method/field qualifier, and qualifier is implicit, asOuterSuper is used in checkMethod, checkIdInternal and memberType.

While these two methods have different use cases, in principle asEnclosingSuper is stricter than asOuterSuper. We speculate that replacing asOuterSuper with asEnclosingSuper can be considered safe. This JBS issue proposes to drop asOuterSuper safely if that is possible (as in the attached patch which represents JDK-8357653 further minimized by dropping asOuterSuper).