¿Por qué Java no es compatible con la inferencia de tipos para los constructores?

Question

E.G. para crear un ArrayList de Strings tenemos que hacer algo como

List<String> list = new ArrayList<String>(); 

mientras que debería ser capaz de inferir el tipo de parámetro para el constructor de modo que sólo tenemos que escribir

List<String> list = new ArrayList(); 

Por qué no puede el tipo se ingiere de la misma manera que los parámetros de tipo se introducen para métodos genéricos.

Answer 1

Esta es una mejora de Java 7 también conocida como el operador de diamantes. La sintaxis será:

List<String> strings = new ArrayList<>(); 

la propuesta oficial, accepted for inclusion in Project Coin es Improved Type Inference for Generic Instance Creation

Según Rémi Forax, el cambio ya está en el repositorio mercurial.

Answer 2

Puede ser y es una característica programada para su inclusión en JDK7.

Answer 3

Se puede inferir el tipo, pero los autores simplemente decidieron que es mejor no tener ninguna inferencia de tipo y luego tener alguna inferencia de tipo limitada en algunos casos.

Si desea realizar inferencias sobre jvm, consulte scala.

Answer 4

Como han dicho otros, esto es on the list for Java 7. Sin embargo, me gustaría señalar que el Google Collections Library ya es compatible con esto para varias colecciones, si está contento de usar importaciones estáticas. Por ejemplo, con frecuencia escribir código como:

List<String> list = newArrayList(); 

Todo lo que necesita es la importación estática y quitar el espacio entre new y ArrayList() :)

(La importación estática sería la de la clase Lists, por cierto . Hay métodos similares para mapas, etc.)

Answer 5

Aparte de características JDK7, supongo que lo que puede utilizar extiende y súper.

class Animal {} 
class Dog extends Animal {} 

List<? extends Animal> anims = new ArrayList<Dog>(); 
List<? super Dog> superdogs = new ArrayList<Animal>(); 

No podría inferir en estos dos casos.

Answer 6

Quiere una razón por la cual Java actual no lo admite.

Solo puedo decir que Java suele dar pequeños pasos siempre que sea posible. Supongo que hubo un pequeño problema técnico que no estaban seguros de obtener "Correcto" antes de Java 7, probablemente algo relacionado con estar absolutamente seguros de que no crearía un caso ambiguo en algún código anterior o no genérico. .

Note como Robert señaló que la sintaxis será la siguiente:

List<String> strings = new ArrayList<>(); 

Aviso al vacío <>? Supongo que es para eliminar la ambigüedad de este tipo de inferencia a partir del código no genérico anterior; probablemente sea algo en lo que no pensaron al principio.

Answer 7

No soy un súper experto en Java, por lo que no estoy completamente seguro de lo que voy a decir. Aquí están mis pensamientos:

Como Java implementa genéricos por borrado, para cada tipo genérico hay un tipo sin procesar subyacente. Si define un tipo genérico, habrá un tipo sin procesar subyacente que usará Object por todas partes.

Cuando se instancia un nuevo ArrayList, sería un error de compilador para inferir el parámetro de tipo de la clase de instancias (ArrayList<String> en su ejemplo), ya que hay una clase con ese nombre exacto y ningún parámetro de tipo (que es la tipo sin procesar, ArrayList). También creo que esta es la razón por la cual en java 7 tendrá que agregar <> a la llamada del constructor para decirle al compilador que deduzca el tipo.

Se podría argumentar que el compilador debe crear una instancia del tipo sin formato solo cuando la clase de definición es el tipo sin formato, pero creo que sería confuso. Creo que el compilador debe inferir a partir de expresiones incompletas que no serían válidas sin un contexto dado, que no es el caso para la declaración new ArrayList().

Espero que esto esté claro, y que si me equivoco alguien me puede corregir.

---

Nota al margen:

Además, ten en cuenta que la clase prima no es el mismo que el tipo usando Object como parámetro de tipo:

List<String> list = new ArrayList(); 

es válida, en tanto que

List<String> list = new ArrayList<Object>(); 

no lo es. En el primer caso, el tipo sin procesar se puede usar como si fuera un tipo genérico, pero en el segundo caso se pregunta por la contravariación que no está disponible (no si no se usan comodines).