2012-01-18 10 views
15

veo desde el javadoc que la anotación se aplica a @SuppressWarnings¿Por qué no puedo suprimir advertencias en un paquete?

TYPE,FIELD,METHOD,PARAMETER,CONSTRUCTOR,LOCAL_VARIABLE 

objetivos. ¿Por qué no se aplica también al PACKAGE?

Tengo un código generado que contiene algunas advertencias de tipos sin formato. Me gustaría poder agregar un archivo package-info.java para las clases generadas (en un directorio físico separado pero el mismo paquete java) que le dice a eclipse que ignore las advertencias de tipos brutos que emanan de las clases generadas en el paquete.

¿Por qué no es compatible? ¿Hay alguna forma alternativa de suprimir una advertencia en un paquete completo?

+1

es su problema igual con [it] (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6299893) –

+1

check [it] (http://stackoverflow.com/questions/1127920/ cómo-suprimir-java-advertencias-para-directorios-específicos-o-archivos-tal-como-generar) por favor –

+1

@faridmovsumov - Estoy teniendo el mismo problema que el "error" de Oracle. Tendré que agregar mis 2 centavos a ese informe de errores cuando pueda buscar mi ID de Oracle. –

Respuesta

7

La razón por la que no se permite la supresión de advertencias a nivel de paquete se explicó en la respuesta a un informe de error anterior (Estado: cerrado, no se corrige): Allow SuppressWarnings to be specified at the package level.

Las advertencias realmente indican problemas potenciales en el código generado .

Actualmente, las Adversiones Supresoras tienen la propiedad deseable de que solo afecta al código anidado léxicamente. Esto significa que usted puede ver inmediatamente si se puede suprimir una advertencia en el código que está leyendo.

Esta propuesta violaría esta propiedad para resolver un problema poco común que en la mayoría de los casos se puede solucionar.

También hay un par de soluciones sugeridas en esa respuesta.

  1. compilar el código generado por sí mismo utilizando -source 1,4 y -target solicitud 5.

  2. una versión actualizada de javacc que o bien utiliza suppresswarnings o no genera código que provoca advertencias.

creo que la primera sugerencia, poner el código generado en su propio proyecto, debe trabajar para usted. La segunda sugerencia parece más específica del problema en el informe de error. No sé si estás usando javacc o no.

+0

Parece que este es un problema más común de lo que Oracle está dispuesto a admitir, en función de la cantidad de comentarios sobre ese error. Compilar para apuntar a la versión 1.5 NO es una solución si desea usar las características 1.6 o 1.7 ... Desafortunadamente, la extracción de código para un proyecto separado no es una solución viable para mí en este caso. –

+0

Esto es deprimente. Especialmente dado el aumento del análisis de código estático y el uso de SuppressWarnings para reducir el foco de los escaneos. En grandes proyectos monolíticos sin la voluntad política de refactorizar el código generado, mover proyectos o generar código en la compilación no suele ser una opción. –

1

Buena pregunta. Probablemente esto sea arreglado por Oracle en el futuro.

Pero ahora puedo sugerirle lo siguiente. Pon todo el código generado en proyecto separado. Por cierto, es una práctica común. Luego configure este proyecto para ser paciente con las advertencias. Por ejemplo, en eclipse puede abrir las propiedades del proyecto/Java Compiler/Errors/Warings, seleccionar "habilitar configuraciones específicas del proyecto" y desactivar todas las advertencias.

+0

No creo que extraer el código generado para un proyecto separado sea una solución viable en este caso. Gracias por la sugerencia, sin embargo. –

+0

"Probablemente esto sea reparado por Oracle en el futuro" me hizo reír a carcajadas. Gracias por eso. – uckelman

Cuestiones relacionadas