为什么编译这段代码会导致编译器堆栈溢出？

Question

interface Pong<T> {}
class Ping<T> implements Pong<Pong<? super Ping<Ping<T>>>> {
    static void Ping() {
        Pong<? super Ping<Long>> Ping = new Ping<Long>();
    }
}

尝试编译此代码会出现错误：

The system is out of resources.
Consult the following stack trace for details.
java.lang.StackOverflowError
    at com.sun.tools.javac.code.Types$23.visitClassType(Types.java:2579)
    at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:554)
    at com.sun.tools.javac.code.Types$UnaryVisitor.visit(Types.java:3260)
    at com.sun.tools.javac.code.Types$23.visitClassType(Types.java:2592)
    at com.sun.tools.javac.code.Types$23.visitClassType(Types.java:2579)
    at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:554)
    ...

代码由 github 上的 etorreborre 提供。

Answer 1

因为编译器无法确定 Long 是否为 Pong（即 Ping 的 super 或 Ping） Long 的 >Ping 或是否是扩展 Pong 的 Ping 的 Ping Pong 的 code> ...但我可能是 错误的。

Answer 2

显然，这是Java编译器中的一个错误。编译器不应该崩溃，尤其是在这么小的程序上。

它甚至可能是 Java 语言规范中的一个漏洞；即 JLS 作者没有考虑到的泛型中一个模糊的边缘情况。

但是（IMO）这只不过是一种好奇，除非你能想出一个不那么明显故意来破坏编译器的例子。我的意思是，这个示例代码并不完全有意义……

---

对 Java 编译器的实现有深入了解的人可能会弄清楚为什么这会导致堆栈溢出。但除非那个人也打算修复这个错误，否则它几乎没有意义。除非有人能提出一个有意义的例子来触发同样的问题，否则我看不到修复它的任何价值。

Answer 3

我有一个同事在实际代码中也有类似的问题。在那里，他有一个带有 2 个类型参数的抽象基类，该基类有两个子类将它们固定为具体类型。基本上，这允许在抽象类中定义完整的逻辑，而不必在具有交换的具体类型的两个子类中复制代码。

基本上，代码是这样的：

public abstract class AImpl<X extends A<Y>, Y extends A<X>> {
    public X foo(Y o) {
        return o.doStuff();
    }

    public Y bar(X o) {
        return o.doStuff();
    }
}

class VImpl extends AImpl<V, E> {}
class EImpl extends AImpl<E, V> {}

interface A<T> {
    T doStuff();
}

interface V extends A<E> {}
interface E extends A<V> {}

该代码实际上可以编译。实际上，不仅有2个子类，还有更深层次的类型层次结构，例如VImpl和EImpl的三个变体，每个变体都有任意多个子类。嗯，实际上，有 3 个类型参数，并且限制有点复杂，如上所示。

当只有 VImpl 和 EImpl 两个变体时，它仍然编译得很好。一旦添加第三个变体，他就会在编译器中出现堆栈溢出。也就是说，Eclipse 编译器仍然能够编译代码，因此看起来它只是 javac 递归地执行一些应该更好地迭代执行的操作。

不幸的是，我们无法将完整的代码库缩减为适合错误报告的最小示例......

Answer 4

我在 JDK 8_u25 中遇到了同样的问题，更新到 JDK 8u_65 解决了这个问题。