programacion operador metodos genericos generica diamante java generics type-inference

operador - Inferencia de tipos genéricos de Java 7: valor de retorno vs argumento de método



operador diamante java (2)

Este es uno de los lugares donde la inferencia de tipos aún no funciona como se esperaba.

Desafortunadamente ese comportamiento es perfectamente válido y conforme.

La buena noticia es que Java 8 incluirá inferencia de tipos mejorada (JEP 101) , por lo que las situaciones como esta deberían compilarse tal como lo esperaría:

Parece razonable que el compilador pueda inferir el tipo cuando el resultado de tal invocación de método genérico se pasa a otro método [...].

Desafortunadamente, esto no está permitido en JDK 5/6/7, la única opción disponible para el programador es usar un tipo de argumento explícito.

Aparte de las mejoras directas (es decir, situaciones como las que menciona aquí), este cambio también es necesario para poder utilizar Lambdas (JEP 126) de manera más eficiente (es decir, sin tener que escribir mucha información de tipo).

Por qué el compilador es capaz de inferir correctamente el parámetro Tipo de String en el caso de un tipo de retorno de función.

public class Generics { private static List<String> function() { return new ArrayList<>(); } }

pero falla cuando el tipo a inferir es un parámetro de método:

public class Generics { public static void main(String[] args) { method(new ArrayList<>()); } private static void method(List<String> list) { } }

El error en este caso es:

The method method(List<String>) in the type Generics is not applicable for the arguments (ArrayList<Object>)


La sección sobre inferir argumentos de tipo no resueltos en JLS es bastante compleja, pero entiendo que el diamante del primer caso ocurre en un lugar donde está sujeto a una conversión de asignación , mientras que en el segundo caso ocurre en una conversión de invocación de método , que sigue diferentes reglas