Dadas las siguientes dos definiciones de clase:

class C1<T extends C1<T>> {}

class C2<U> extends C1<C2<U>> {}

Considere la siguiente declaración de tipo:

C1<? extends C2<String>> c;

Esto se compila bien en JDK-8u45, pero si examinamos elespecificación para la conversión de captura, me parece que esta declaracióndebería resultar en un error de tiempo de compilación.

En particular, el límite superior de la nueva captura de variable de tipoT#1 es dado porglb(Bi, Ui[A1:=S1,...,An:=Sn]), donde en este casoBi resuelve el comodín enlazadoC2<String> yUi[A1:=S1,...,An:=Sn] resuelve aC1<T#1>.

De esto,glb(C2<?>, C1<T#1>) resuelve el tipo de intersecciónC2<String> & C1<T#1>, que no es válido, porqueC2<String> yC1<T#1> son ambos tipos de clase, no tipos de interfaz, pero ninguno de ellos es un subtipo del otro.

Esta (aparente) violación de la regla quizás se aclare más en eldefinición del tipo de intersección sí mismo.

Estoy seguro de que no es un error y solo estoy cometiendo algunos errores simples en alguna parte ... Si es un error, espero que pueda considerarse un error en el JLS y no en el JDK, de modo que pueda esperar poder emular el comportamiento de forma segura ...

¡Gracias por cualquier ayuda!

Editar: Después de hablar ayer con Radiodef, me convencí de que el problema (o al menos una forma de verlo) es queC2<String> se puede pensar efectivamente como un subtipo deC1<T#1>, ya que T # 1 solo puedesiempre estar satisfecho porC2<String> y, por lo tanto, puede considerarse igual a él, pero las reglas de contención y subtipo no comprenden esta relación como está escrita, por lo que el JLS no reconocerá el subtipo y debería fallar ...

Si tomas el caso un poco más complejo deC1<? extends C2<?>> d;Sin embargo, es más complicado. El problema es similar, pero el tipo de intersección que forma el límite superior de la captura aparece comoC2<?> & C1<T#2>, donde no parece que se pueda llegar a una solución con el mismo razonamiento que el anterior.