Pregunta

I se trasladó a una nueva máquina que cuenta con la última compilador de Java de Sun y se dio cuenta algunas advertencias en el 6 código Java existente. El IDE Eclipse, me sugirió que anoto la asignación con:

@SuppressWarnings("rawtypes")

Por ejemplo:

class Foo<T> {
...
}
...
@SuppressWarnings("rawtypes")
Foo foo = new Foo();

Cuando me mudé de nuevo a la máquina con el compilador de más edad (JDK 1.6.0_20), me he dado cuenta de que este compilador mayores ahora advierte sobre la supresión de advertencias "rawtypes", afirmando que esta supresión no es compatible y que propone para reemplazarlo con @SuppressWarnings ( "sin control"). Además, había algunos lugares que el nuevo compilador, por defecto, hace que me ponga ambas "sin control" y "rawtypes" - compilar el código con el compilador mayores reproduce la misma advertencia

.

¿Cómo puedo hacer cumplir la compatibilidad hacia atrás / adelante entre los dos, de modo que ni compilador produce advertencias?

¿Fue útil?

Solución

Puede utilizar el @SuppressWarnings("unchecked") que es apoyada tanto por el compilador de Eclipse y javac.

Pero recuerde la anotación @SuppressWarnings es utilizado por el compilador que puede tener sus propios valores. Las únicas fuerzas JLS el compilador de comprender los valores "sin control" y "obsoleto" (por ahora).

  

fabricantes de compiladores deben documentar los nombres de advertencia que apoyan conjuntamente con este tipo de anotación. Se les anima a cooperar para asegurar que los mismos nombres funcionan a través de múltiples compiladores .

Si utiliza Helios, que tendrá que establecer una opción específica para permitir @SuppressWarnings("unchecked") en lugar de @SuppressWarnings("rawtypes"),

  

En caso de que no es posible actualizar el código con el nuevo token, la propiedad del sistema suppressRawWhenUnchecked=true se puede establecer cuando se inicia Eclipse.


Recursos:


EDIT: Aquí está el artículo ya no está disponible Knol que se utilizó como referencia, escrito originalmente por Alex Miller .

  

@SuppressWarnings anotación en Java

     

anotación estándar para la supresión de varias advertencias

     

La anotación SuppressWarnings se añadió como una anotación estándar en Java SE 5.

     

Definición

     

La @ SuppressWarnings anotación se define en la especificación del lenguaje Java sección 9.6.1.5 . En esta sección se establece lo siguiente:

     
    

El tipo de anotación de control soportes SuppressWarnings programador sobre advertencias emitidas de otro modo por el compilador de Java. Contiene un solo elemento que es una matriz de String. Si una declaración programática está anotado con la anotación @SuppressWarnings(value = {S1, ... , Sk}), a continuación, un compilador Java no debe reportar cualquier advertencia identificado por uno de S1, ..., Sk si esa advertencia se habría generado como resultado de la declaración anotada o cualquiera de sus partes .

         

Sin marcar las advertencias se identifican por la cadena "unchecked".

  
     

El subsiguiente en @Deprecation también menciona que estas advertencias se pueden suprimir con @SuppressWarnings("deprecation").

     

Tipos de advertencia válidos

     

Las únicas dos cadenas de advertencia que se mencionan en la misma especificación son "sin control" y "desaprobación". Sin embargo, el JDK de Sun utiliza un conjunto mayor de cadenas en el compilador. Se puede determinar la corriente establecida por la ejecución de:

javac -X
     

que le mostrará (entre otras cosas) los valores válidos para -Xlint.

     

Por ejemplo, Sun JDK 1.5 muestra:

     
      
  • todo - suprimir todas las advertencias de este código
  •   
  • deprecation - advertencias a suprimir el uso de código obsoleto
  •   
  • sin control - a suprimir las advertencias de una llamada sin marcar o un elenco sin control
  •   
  • fallthrough - advertencias Suprimir si un interruptor cae a través sin encontrar un caso válido (y no tiene valor predeterminado)
  •   
  • ruta -
  •   
  • serie - advertencias a suprimir si una clase Serializable no define un serialVersionUID
  •   
  • finalmente - a suprimir las advertencias de retorno dentro de un fin (que ignore retorno con el intento)
  •   
     

Y Sun JDK 1.6 añade:

     
      
  • Reparto
  •   
  • divzero - advertencias a suprimir si se detecta número entero división por cero
  •   
  • vacío
  •   
  • anulaciones
  •   
  • no
  •   
     

IDEs y herramientas de análisis estático apoyan típicamente un gran número de otros valores posibles para @SuppressWarnings. Estos valores corresponden a los controles de análisis específico estáticas realizados por el IDE.

     

Eclipse

     

Los valores de alerta para Eclipse Eclipse 3.3 son documentado en la documentación JDT .

     
      
  • todo - suprimir todas las advertencias
  •   
  • boxeo - advertencias a suprimir en relación con el boxeo / unboxing operaciones
  •   
  • Reparto - advertencias a suprimir relativos a las operaciones de fundición
  •   
  • dep-ann - advertencias a suprimir en relación con obsoleta anotación
  •   
  • deprecation - advertencias a suprimir en relación con desaprobación
  •   
  • fallthrough - advertencias a suprimir relativas a roturas en las instrucciones switch faltante
  •   
  • finalmente - a suprimir las advertencias relativas a bloquear, finalmente, que no vuelven
  •   
  • escondite - advertencias relativas a suprimir a los locales que ocultan la variable
  •   
  • incompleta-switch - advertencias a suprimir relativos a las entradas que faltan en una sentencia switch (caso de enumeración)
  •   
  • nls - advertencias a suprimir en relación con los no-nls literales de cadena
  •   
  • null - advertencias a suprimir en relación con el análisis nulo
  •   
  • restricción - advertencias Suppress relativos al uso de desanimado o referencias prohibidos
  •   
  • serie - advertencias a suprimir relativa a la falta de campo serialVersionUID para una clase serializable
  •   
  • estática de acceso - a suprimir las advertencias en relación con el acceso estático incorrecto
  •   
  • sintético de acceso - advertencias a suprimir en relación con el acceso sin optimizar de clases internas
  •   
  • sin control - a suprimir las advertencias en relación con las operaciones sin marcar
  •   
  • campo de acceso sin reservas - advertencias a suprimir en relación con el acceso de campo sin reservas
  •   
  • inusitado - advertencias a suprimir en relación con código no utilizado
  •   
     

IntelliJ

     

NetBeans

     

Ejemplos

     

Un ejemplo de la especificación de un solo aviso:

@SuppressWarnings("unchecked")
public void methodWithScaryWarnings() {
    List rawList = new ArrayList();
    List<String> stringList = (List<String>)rawList;
}
     

Un ejemplo del uso de dos advertencias:

@SuppressWarnings({"unchecked","deprecation"})
public void methodWithScaryWarnings() {
    callDeprecatedMethod();
}

Otros consejos

Tenga en cuenta que Eclipse 3.5 duerma entender rawtypes y banderas de advertencia a un interruptor para marcar. Es frustrante que Eclipse se le ocurrió rawtypes anotación que causa más problemas que resolver. Ellos deberían haber pegado con el estándar.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top