inferencia Genérico en los constructores

Question

Si tengo una clase Foo:

public class Foo<T> { 
    public Foo(T t) { 
     //do something 
    } 

    public static <E> void bar(E e) { 
     //do something 
    } 
} 

¿Por qué Foo.bar("String"); inferir que E es una cadena (y por lo tanto no lanzar una advertencia del compilador), pero no new Foo("String"); inferir que T es una cadena?

Answer 1

Como el constructor se puede considerar como un método de instancia especial, no se escribe - obtiene su tipo del nombre de clase (con un parámetro de tipo), por ejemplo Foo<String>. es decir, el constructor no se define como:

public <T> Foo(T t) ... 

ni puede ser. Si lo hace, podría ocultar el tipo genérico de la clase (y obtendrá una advertencia)

El método estático sin embargo es mecanografiado. Para su información, la llamada genérica, sin parámetros, una vez que se infiere del tipo, es equivalente a:

Foo.<String>bar("String"); 

Answer 2

creo que necesita para hacer esto

new Foo<String>("String"); 

a decir obtener la información de los genéricos pasado; similar a la API de Colecciones.

Answer 3

Buscando en esto, voy a tomar una conjetura aquí. Considere lo siguiente:

public class Foo { 
    public <E> Foo(E t) { 
     //do something 
    } 

    public static <E> void bar(E e) { 
     //do something 
    } 
} 

En la clase anterior se obtiene ninguna advertencia cuando una instancia de Foo de la siguiente manera:

Foo f = new Foo("String"); 

Esto funciona porque el tipo de E se infiere aquí. Tal como espera que ocurra en el caso del método. Sin embargo, el error que está obteniendo no se debe a que el tipo de argumento no se esté inferiendo, sino porque no se puede inferir el tipo sin procesar para la clase.

Creo que esto se debe a que el tipo de clase sin formato se puede propagar a los métodos, pero los métodos no pueden establecer el tipo de clase sin procesar mediante la inferencia.

Answer 4

Cuando Java implementó genéricos, se decidió que una clase genérica instanciada sin parámetros de tipo siempre devolvería un tipo sin formato. Esto difiere de los métodos genéricos que faltan parámetros de tipo, que el compilador intenta inferir el tipo de. De los tutoriales de Java:

En general, el compilador de Java puede inferir los parámetros de tipo de una llamada al método genérico. En consecuencia, en la mayoría de los casos, no es necesario que los especifique.

Pero cuando la discusión se dirige a los constructores:

Tenga en cuenta que para tomar ventaja de la inferencia de tipo automático durante la instanciación de la clase genérica, debe especificar el diamante.En el siguiente ejemplo, el compilador genera una advertencia de conversión sin control debido a que el HashMap() constructor se refiere al tipo prima HashMap, no el tipo Map<String, List<String>>:

Map<String, List<String>> myMap = new HashMap(); // unchecked conversion warning

fuente: http://download.oracle.com/javase/tutorial/java/generics/gentypeinference.html

Esto sigue siendo lo mismo en Java 7, sin embargo, trataron de hacerlo menos repetitivo al admitir la sintaxis del diamante. Por ejemplo, Foo<String> foo = new Foo<>("String"). Ver this section of the same article.

Answer 5

@Kublai Khan tiene la respuesta correcta; el tipo de new Foo(s) es raw Foo, para compatibilidad con versiones anteriores.

La inferencia del tipo de diamante del constructor de Java7 (new Foo<>(s)) es la misma, y ​​se define en términos de, la inferencia del tipo de método en el método.

http://cr.openjdk.java.net/~darcy/ProjectCoin/ProjectCoin-Documentation-v0.9375.html#diamond

Si la expresión creación de la instancia de clase utiliza "<>" para eludir argumentos de tipo de clase, una lista de métodos m1 ... mk se definen a los efectos de la resolución de sobrecarga y la inferencia tipo de argumento. ..

... entonces uno de m1 ... mk se selecciona, utilizando el proceso descrito en §15.12.2 (Determinar Método Signature)

Su sospecha es correcta, constructores c una inferencia de uso al igual que los métodos, no hay diferencias esenciales. Solo tiene que agregar <> debido a un problema de compatibilidad con versiones anteriores.

Por qué Java tardó 6 años en agregar esta función es otra historia.