2012-06-25 20 views
16

Utilizamos algunas funciones varargs y cuando nos movemos a java 1.7 recibimos una extraña advertencia no verificada.Función de Java 1.7 varargs informada como advertencia no marcada

Función añadir en iCache interfaz

public interface ICache<O> { 
    void add(Object source, O... objects); 
} 

en una interfaz informa del error.

ICache.java:18: warning: [unchecked] Possible heap pollution from parameterized vararg type O 
    void add(Object source, O... objects); 
    where O is a type-variable: 
    O extends Object declared in interface ICache 
1 warning 

O extends Object, como su clase de caché genérica.

He leído las advertencias de xlint y compilamos sin marcar, pero http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javac.html#xlintwarnings parece implicar que este error debe ser del tipo [varargs] y no anulado.

¿Echo de menos algo?

+0

¿Podemos ver todas las partes relevantes de ICache y SomeClass? –

+0

Editado para agregar fuente. –

+1

Eche un vistazo a [este sitio oficial de Oracle] (http://docs.oracle.com/javase/7/docs/technotes/guides/language/non-reifiable-varargs.html), explica varargs montón contaminación en detalle , ¿por qué el compilador de Java 7 genera una advertencia y cómo puede suprimirlo? – buc

Respuesta

2

Contaminación de montón es un término que hace referencia a un tipo que apunta a un objeto que no es el supertipo de cuando se usan varargs con un tipo genérico. Ocurre cuando una variable de un tipo parametrizado se refiere a un objeto que no es de ese tipo parametrizado. This publicación en desbordamiento de pila explica exactamente lo que significa esto y lo que debe hacer al respecto, y proporciona detalles sobre la anotación @SafeVarargs. Por lo tanto, en la interfaz ICache, vararg tipo O apunta a Object en su interfaz, pero O no es el supertipo de Object, y esto genera una advertencia de contaminación de pila. Observe cómo dice posible contaminación del montón. Si su código no está causando ningún problema como conducir a ClassCastException, probablemente sea seguro y no contamine el montón, pero el compilador no tiene forma de probar esto y no puede verificar la corrección de la operación, por lo que generará la advertencia. Esa es en realidad la definición de una advertencia no verificada: cuando no se puede verificar la corrección de una operación que involucra un tipo parametrizado. Consulte this Página de Oracle en tipos no reificables para obtener más información. Si no desea recibir esta advertencia, puede evitarla con SafeVarargs, o simplemente suprimirla agregando @SuppressWarnings ({"unchecked", "varargs"}) a la declaración del método, pero no recibirá la advertencia en caso de que el método sea inseguro.

Cuestiones relacionadas