这个类:

public class OuterChild extends OuterChild.InnerParent {
    public static class InnerParent {
    }
}

编译失败:

$ javac OuterChild.java
OuterChild.java:1: error: cyclic inheritance involving OuterChild
public class OuterChild extends OuterChild.InnerParent {
       ^
1 error

因为 OuterChild 会“依赖于”自身，因为(根据 §8.1.4 "Superclasses and Subclasses" of The Java Language Specification, Java SE 8 Edition )一个类直接依赖于“[its] extends 中提到的任何类型或实现子句 […] 作为父类(super class)或超接口(interface)名称的完全限定形式的限定符。”

但我不太明白这里的动机。有问题的依赖性是什么？是否只是为了与 InnerParent 是非 static 的情况保持一致(因此最终会得到一个词法封闭的自身实例)？

最佳答案

这似乎是一个相当邪恶的极端案例，因为有一个 number of bugs与循环继承有关，通常会导致编译器中的无限循环、堆栈溢出和 OOM。以下是一些可能提供一些见解的相关引述:

Bug 4326631 :

This example is not legal, and this is made clear in the forthcoming 2nd edition of the Java Language Specification. Classes simultaneously related by both inheritance and enclosure are problematical, however the original innerclasses whitepaper did not adequately address the issue, nor did the pre-1.3 compilers implement a consistent policy. In JLS 2nd edition, the rule against cyclic inheritance has been extended to prohibit a class or interface from "depending" on itself, directly or indirectly. A type depends not only on types that it extends or implements, but also on types that serve as qualifiers within the names of those types.

Bug 6695838 :

The two class declarations are indeed cyclic; accordingly to JLS 8.1.4 we have that:

Foo depends on Foo$Intf (Foo$Intf appears in the implements clause of Foo)
Foo$Intf depends on Moo$Intf (Moo$Intf appears in the extends clause of Foo$Intf)
Foo$Intf depends on Foo (Foo appears as a qualifier in the extends clause of Foo$Intf)

For transitivity, we have that Foo depends on itself; as such the code should be rejected with a compile-time error.

Bug 8041994 :

Stepping back, the directly-depends relationship for classes and interfaces was introduced in JLS2 to clarify JLS1 and to cover superclasses/superinterfaces that are nested classes (e.g. A.B in the Description).

Bug 6660289 :

This problem is due to the order in which javac perform attribution of type-variable bounds wrt class attribution.

1) Attribution of class Outer<T extends Outer.Inner>
1a) Attribution of Outer triggers attribution of Outer's type variable
2) Attribution of Outer.T
2a) Attribution of Outer.T triggers attribution of its declared bound
3) Attribution of class Outer.Inner<S extends T>
3a) Attribution of Outer.Inner triggers attribution of Outer.Inner's type variable
4) Attribution of Outer.Inner<S>
4a) Attribution of Outer.Inner.S triggers attribution of its declared bound
5) Attribution of Outer.T - this does nothing but returning the type of T; as you can see, at this stage T's bound has not been set yet on the object representing the type of T.

At a later point, for each attributed type variable, javac performs a check to ensure that the bound of a given type variable does not introduce cyclic inheritance. But we have seen that no bound is set for Outer.T; for this is the reason javac crashes with a NPE when trying to detect a cycle in the inheritance tree induced by the declared bound of Outer.Inner.S.

Bug 6663588 :

Type-variable bounds might refer to classes belonging to a cyclic inheritance tree which causes the resolution process to enter a loop when looking up for symbols.

对于“有问题的依赖项是什么？”的具体问题，它似乎是一个复杂的编译时符号解析边缘案例，而 JLS2 中引入的解决方案只是简单地禁止由引入的循环限定符类型以及实际父类(super class)型。

换句话说，理论上这可以通过对编译器进行适当的改进来实现，但在有人出现并实现这一点之前，在语言规范中禁止这种不寻常的关系更为实际。

关于java - 为什么类不能扩展其中出现的静态嵌套类？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/29225190/