¿Cómo funcionan los genéricos de los genéricos?

No hay un error potencial de tiempo de ejecución, está justo fuera de la capacidad del compilador para determinar estáticamente eso. Cada vez que causa una inferencia de tipo, genera automáticamente una nueva captura de <? extends Number>, y dos capturas no se consideran equivalentes.

Por lo tanto, si elimina la inferencia de la invocación de singletonList especificando <T> para ello:

List<Test<? extends Number>> l = Collections.<Test<? extends Number>>singletonList(t);

Funciona bien. El código generado no es diferente de si su llamada hubiera sido legal, es solo una limitación de la compilador que no puede averiguar eso por sí solo.

La regla de que una inferencia crea una captura y las capturas no son compatibles es lo que impide que este ejemplo de tutorial se compile y luego explote en tiempo de ejecución:

public static void swap(List<? extends Number> l1, List<? extends Number> l2) {
    Number num = l1.get(0);
    l1.add(0, l2.get(0));
    l2.add(0, num);
}

Sí, la especificación del lenguaje y el compilador probablemente podrían hacerse más sofisticados para distinguir su ejemplo de eso, pero no lo es y es lo suficientemente simple como para evitarlo.

Tal vez esto pueda explicar el problema del compilador:

List<? extends Number> myNums = new ArrayList<Integer>();

Esta lista de comodines genric puede contener cualquier elemento que se extienda desde Number. Así que está bien asignarle una lista entera. Sin embargo, ahora podría agregar un Doble a myNums porque el Doble también se extiende desde el Número, lo que llevaría a un problema de tiempo de ejecución. Por lo tanto, el compilador prohíbe todos los accesos de escritura a myNums y solo puedo usar métodos de lectura en él, porque solo sé lo que consigo se puede convertir en Número.

Y así el el compilador se queja de muchas cosas que puede hacer con un comodín genérico. A veces él está loco por las cosas que usted puede asegurarse de que están a salvo y bien.

Pero afortunadamente hay un truco para evitar este error para que pueda probar por su cuenta lo que tal vez puede romper esto:

public static void main(String[] args) {

    List<? extends Number> list1 = new ArrayList<BigDecimal>();
    List<List<? extends Number>> list2 = copyHelper(list1);


}

private static <T> List<List<T>> copyHelper(List<T> list) {
    return Collections.singletonList(list);

}

La razón es que el compilador no sabe que sus tipos comodín son del mismo tipo .

Tampoco sabe que tu instancia es null. Aunque null es un miembro de todos los tipos, el compilador considera solo los tipos declarados, no lo que el valor de la variable podría contener, cuando se verifica el tipo.

Si el código se ejecuta, no causaría una excepción, pero eso es solo porque el valor es null. Todavía existe un posible desajuste de tipo, y eso es lo que el trabajo del compilador es-para no permitir los desajustes de tipo.

Echa un vistazo a type erasure. El problema es que el "tiempo de compilación" es la única oportunidad que Java tiene para hacer cumplir estos genéricos, por lo que si lo deja pasar no sería capaz de decir si intentó insertar algo inválido. Esto es realmente algo bueno, porque significa que una vez que el programa compila, los genéricos no incurren en ninguna penalización de rendimiento en tiempo de ejecución.

Vamos a tratar de ver su ejemplo de otra manera (vamos a usar dos tipos que extienden el Número pero se comportan muy diferente). Considere el siguiente programa:

import java.math.BigDecimal;
import java.util.*;

public class q16449799<T extends Number> {
  public T val;

  public static void main(String ... args) {
    q16449799<BigDecimal> t = new q16449799<>();
    t.val = new BigDecimal(Math.PI);

    List<q16449799<BigDecimal>> l = Collections.singletonList(t);
    for(q16449799<BigDecimal> i : l) {
      System.out.println(i.val);
    }
  }
}

Esto produce (como uno esperaría):

3.141592653589793115997963468544185161590576171875

Ahora asumiendo que el código que presentaste no causó un error de compilador:

import java.math.BigDecimal;
import java.util.concurrent.atomic.AtomicLong;

public class q16449799<T extends Number> {
  public T val;

  public static void main(String ... args) {
    q16449799<BigDecimal> t = new q16449799<>();
    t.val = new BigDecimal(Math.PI);

    List<q16449799<AtomicLong>> l = Collections.singletonList(t);
    for(q16449799<AtomicLong> i : l) {
      System.out.println(i.val);
    }
  }
}

¿Qué esperarías que fuera la salida? No puedes razonablemente lanzar un BigDecimal a un AtomicLong (podrías construir un AtomicLong a partir del valor de un BigDecimal, pero el casting y la construcción son cosas diferentes y los genéricos se implementan como sugar en tiempo de compilación para asegurarte de que los casts sean exitoso). En cuanto al comentario de @KennyTM, se busca un tipo concreto cuando inicias el ejemplo, pero intenta compilar esto:

import java.math.BigDecimal;
import java.util.*;

public class q16449799<T> {
  public T val;

  public static void main(String ... args) {
    q16449799<? extends Number> t = new q16449799<BigDecimal>();

    t.val = new BigDecimal(Math.PI);

    List<q16449799<? extends Number>> l = Collections.<q16449799<? extends Number>>singletonList(t);
    for(q16449799<? extends Number> i : l) {
      System.out.println(i.val);
    }
  }
}

Esto se producirá un error en el momento en que intente establecer un valor en t.val.