У меня есть коллега, у которого похожая проблема в реальном коде. Там у него есть абстрактный базовый класс с двумя параметрами типов, который имеет два подкласса, фиксирующих их на конкретные типы. По сути, это позволяет определить полную логику в абстрактном классе, вместо того чтобы дублировать код в обоих подклассах с замененными конкретными типами.
По сути, код выглядит примерно так:
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 делает что-то рекурсивное, что лучше делать итеративно.
К сожалению, мы не можем сократить полную базу кода до некоторого минимального примера, подходящего для сообщения об ошибке ...