¿Cuándo requieren los genéricos de Java en lugar de y ¿hay algún inconveniente de la conmutación?

Gracias a todos los que respondieron a la pregunta, realmente me ayudó a aclarar las cosas. Al final, la respuesta de Scott Stanchfield se acercó más a cómo terminé entendiéndolo, pero como no lo entendí cuando lo escribió por primera vez, estoy tratando de replantear el problema para que esperemos que alguien más se beneficie.

Voy a replantear la pregunta en términos de Lista, ya que solo tiene un parámetro genérico y eso lo hará más fácil de entender.

El propósito de la clase parametrizada (como List<Date> o Map<K, V> como en el ejemplo) es forzar un downcast y hacer que el compilador garantice que esto es seguro (sin excepciones de tiempo de ejecución).

Considere el caso de List. La esencia de mi pregunta es por qué un método que toma un tipo T y una Lista no aceptará una Lista de algo más abajo en la cadena de herencia que T. Considere este ejemplo artificial:

List<java.util.Date> dateList = new ArrayList<java.util.Date>();
Serializable s = new String();
addGeneric(s, dateList);

....
private <T> void addGeneric(T element, List<T> list) {
    list.add(element);
}

Esto no compilará, porque el parámetro list es una lista de fechas, no una lista de cadenas. Los genéricos no serían muy útiles si esto compilara.

Lo mismo se aplica a un Mapa<String, Class<? extends Serializable>> No es lo mismo que un Mapa<String, Class<java.util.Date>>. No son covariantes, así que si quisiera tomar un valor del mapa que contiene clases de fecha y ponerlo en el mapa que contiene elementos serializables, está bien, pero una firma de método que diga:

private <T> void genericAdd(T value, List<T> list)

Quiere ser capaz de hacer ambas cosas:

T x = list.get(0);

Y

list.add(value);

En este caso, a pesar de que el el método junit realmente no se preocupa por estas cosas, la firma del método requiere la covarianza, que no está obteniendo, por lo tanto, no compila.

Sobre la segunda cuestión,{[12]]}

Matcher<? extends T>

Tendría la desventaja de aceptar realmente cualquier cosa cuando T es un Objeto, que no es la intención de las API. La intención es garantizar estáticamente que el matcher coincida con el objeto real, y no hay forma de excluir el objeto de ese cálculo.

La respuesta a la tercera la pregunta es que nada se perdería, en términos de funcionalidad sin verificar (no habría encasillamiento inseguro dentro de la API de JUnit si este método no se generalizara), pero están tratando de lograr algo más: asegurarse estáticamente de que los dos parámetros probablemente coincidan.

EDITAR (después de más contemplación y experiencia):

Uno de los grandes problemas con la firma del método assertThat es los intentos de equiparar una variable T con un parámetro genérico de T. Que no funciona, porque no son covariantes. Así, por ejemplo, puede tener una T que es un List<String> pero luego pasar una coincidencia que el compilador trabaja a Matcher<ArrayList<T>>. Ahora, si no fuera un parámetro de tipo, las cosas estarían bien, porque List y ArrayList son covariantes, pero ya que los genéricos, en lo que respecta al compilador require ArrayList, no puede tolerar una Lista por razones que espero sean claras de lo anterior.

Se reduce a:

Class<? extends Serializable> c1 = null;
Class<java.util.Date> d1 = null;
c1 = d1; // compiles
d1 = c1; // wont compile - would require cast to Date

Puede ver que la referencia de Clase c1 podría contener una instancia larga (ya que el objeto subyacente en un momento dado podría haber sido List<Long>), pero obviamente no se puede convertir a una Fecha ya que no hay garantía de que la clase "desconocida" fuera Date. No es typsesafe, por lo que el compilador no lo permite.

Sin embargo, si introducimos algún otro objeto, digamos List (en su ejemplo este objeto es Matcher), entonces lo siguiente se convierte en verdadero:

List<Class<? extends Serializable>> l1 = null;
List<Class<java.util.Date>> l2 = null;
l1 = l2; // wont compile
l2 = l1; // wont compile

...Obstante, si el tipo de la Lista se convierte ? extiende T en lugar de T....

List<? extends Class<? extends Serializable>> l1 = null;
List<? extends Class<java.util.Date>> l2 = null;
l1 = l2; // compiles
l2 = l1; // won't compile

Creo que al cambiar Matcher<T> to Matcher<? extends T>, básicamente estás introduciendo el escenario similar a asignar l1 = l2;

Sigue siendo muy confuso tener comodines anidados, pero espero que eso tenga sentido en cuanto a por qué ayuda a entender los genéricos mirando cómo se pueden asignar referencias genéricas entre sí. También es más confuso ya que el compilador está inferiendo el tipo de T cuando haces la llamada a la función (eres no diciendo explícitamente que era T es).

La razón por la que su código original no se compila es que <? extends Serializable> no significa "cualquier clase que se extiende Serializable", sino "alguna clase desconocida pero específica que se extiende Serializable."

Por ejemplo, dado el código tal como está escrito, es perfectamente válido asignar new TreeMap<String, Long.class>()> a expected. Si el compilador permitía compilar el código, el assertThat() presumiblemente se rompería porque esperaría objetos Date en lugar de los objetos Long que encuentra en el mapa.

Una forma de entender los comodines es pensar que el comodín no especifica el tipo de los posibles objetos que una referencia genérica dada puede "tener", sino el tipo de otras referencias genéricas con las que es compatible (esto puede sonar confuso...) Como tal, la primera respuesta es muy engañosa en su redacción.

En otras palabras, List<? extends Serializable> significa que puede asignar esa referencia a otras Listas donde el tipo es un tipo desconocido que es o una subclase de Serializable. NO piénsalo en términos de UNA SOLA LISTA capaz de contener subclases de Serializable (porque eso es una semántica incorrecta y conduce a un malentendido de los genéricos).

Sé que esta es una pregunta antigua, pero quiero compartir un ejemplo que creo que explica los comodines acotados bastante bien. java.util.Collections ofrece este método:

public static <T> void sort(List<T> list, Comparator<? super T> c) {
    list.sort(c);
}

Si tenemos una Lista de T, la Lista puede, por supuesto, contener instancias de tipos que se extienden T. Si la Lista contiene Animales, la Lista puede contener tanto Perros como Gatos (ambos Animales). Los perros tienen una propiedad " woofVolume "y los gatos tienen una propiedad" meowVolume."Si bien nos gustaría ordenar en función de estas propiedades particulares a subclases de T, ¿cómo podemos esperar que este método haga eso? Una limitación del Comparador es que solo puede comparar dos cosas de un solo tipo (T). Por lo tanto, requerir simplemente un Comparator<T> haría que este método sea utilizable. Pero, el creador de este método reconoció que si algo es un T, entonces también es una instancia de las superclases de T. Por lo tanto, nos permite usar un Comparador de T o cualquier superclase de T, es decir, ? super T.

Y si usa

Map<String, ? extends Class<? extends Serializable>> expected = null;