Revisión de código - Notas de release


1.0 Problemas conocidos
   1.1 El código fuente no se revisa en algunos paquetes
   1.2 El número de línea no se visualiza siempre
   1.3 Las variables de datos internas de las clases JSDK o J2EE no deben aparecer en la vía de acceso de flujo de datos
   1.4 Puede establecer la profundidad en valores negativos en Principios de diseño / Reglas de complejidad
   1.5 Codificación al crear una regla utilizando caracteres ASCII no US en sus parámetros
   1.6 El progreso no está adecuadamente reportado para las reglas de análisis estructural
   1.7 En la vista principal el botón Detener/Iniciar se convierte en una amalgama
   1.8 El arreglo rápido para la regla "Evitar la utilización de java.lang.String.compareTo () para comparar series sensibles al entorno local" propone una solución incorrecta
   1.9 Problema con algunas creaciones de instancias de la regla de plantilla de J2EE: Llamar siempre [método A] después del [método B]
   1.10 Problema potencial con la regla de plantilla de J2EE: Llamar siempre al [método A] después del [método B]
   1.11 Positivo falso en la regla definida por el usuario Evitar método de definición
   1.12 Las plantillas que toman un método no funcionan al teclear un nombre de método
   1.13 La ventana del error observado aparece al intentar configurar datos de servidor

1.0 Problemas conocidos

1.1 El código fuente no se revisa en algunos paquetes

El origen contenido en los paquetes siguientes no será revisado por algunas de las reglas de procedimientos recomendados de J2EE:
1. com.ibm
2. COM.ibm
3. sun
4. sunw
5. java
6. javax
7. org.apache
8. com.sun
9. org.omg
10. org.ietf
11. org.w3c
12. org.xml

1.2 El número de línea no se visualiza siempre

En la vista Revisión de código, el número de línea no se visualiza siempre para algunos de los hallazgos detectados por las reglas de prácticas recomendadas de J2EE. Si efectúa una doble pulsación sobre el hallazgo, aparecerá en el número de línea correcto.

1.3 Las variables de datos internas de las clases JSDK o J2EE no deben aparecer en la vía de acceso de flujo de datos

Una vía de acceso de flujo de datos muestra la historia de dependencia de los cambios de datos que llevan a un problema resaltado por un hallazgo de regla. Las vías de acceso de flujo de datos aparecen en la pestaña Vía de acceso. A veces, las vías de acceso de flujo de datos visualizan estructuras de datos presentes en las clases JSDK o J2EE. Por ejemplo, en lugar de decir que se ha modificado una variable de tipo java.lang.Vector, verá que se ha modificado java.lang.Object[]variable. Esto es un campo interno de la implementación de java.lang.Vector y puede inducir a confusión el hecho de ver esta información privada visualizada en la pestaña.

1.4 Puede establecer la profundidad en valores negativos en Principios de diseño / Reglas de complejidad

En la categoría de regla de Principios de diseño, puede establecer la profundidad de las reglas de complejidad. Por ejemplo, puede cambiar la regla "Evitar la anidación de más de una 1 clase(s)" por "Evitar la anidación de más de 3 clas(es)." Para que la regla funcione correctamente, debe utilizar un número positivo para la profundidad. Sin embargo, las reglas de complejidad no aseguran actualmente que la profundidad se establezca en un número positivo. Para evitar este caso, no especifique una entrada no válida como por ejemplo cero o un número negativo.

1.5 Codificación al crear una regla utilizando caracteres ASCII no US en sus parámetros

Hay un problema de codificación al crear una regla a partir de una plantilla utilizando caracteres ASCII no US en sus parámetros. Esto pasa por ejemplo, cuando se selecciona un tipo o un método con caracteres locales. Debido a este tema de codificación, cuando se ejecutan las reglas que se crean con estas propiedades y con caracteres ASCII no US, se genera una excepción.

1.6 El progreso no está adecuadamente reportado para las reglas de análisis estructural

El progreso de la Revisión de código no está adecuadamente reportado para las reglas de análisis estructural (es decir, el diálogo de progreso siempre informa del 100% del progreso). Debe esperar a que termine la Revisión de código.

1.7 En la vista principal el botón Detener/Iniciar se convierte en una amalgama

Ocasionalmente, al iniciar la Revisión de código el botón Iniciar/Detener muestra un icono que es una combinación de iniciar y detener.

1.8 El arreglo rápido para la regla "Evitar la utilización de java.lang.String.compareTo () para comparar series sensibles al entorno local" propone una solución incorrecta

El arreglo rápido para la regla "Evitar la utilización de java.langString.compareTo () para comparar series sensibles al entorno local" propone dos soluciones para arreglar el problema detectado por la regla. La solución que sugiere <Utilice com.ibm.icu.text.Collator> no es correcta. La solución debería ser <Utilice java.text.Collator>.

1.9 Problema con algunas creaciones de instancias de la regla de plantilla de J2EE: Llamar siempre [método A] después del [método B]

Si crea una regla nueva con la plantilla de regla de J2EE "Llamar siempre [método A] después del [método B]," cuando [método B] es un constructor predeterminado en el área de trabajo y cuando la regla se ejecuta en una revisión de código, la regla no generará hallazgos de regla.

1.10 Problema potencial con la regla de plantilla de J2EE: Llamar siempre al [método A] después del [método B]

Al crear una regla nueva para una instancia de objeto específica de la regla de plantilla de procedimientos recomendados de J2EE: "Llamar siempre al [método A] después del [método B]" puede generar hallazgos de regla incorrectos en el próximo caso específico para el que se define una regla. Si selecciona métodos del patrón "Llamar siempre al [método A] después del [método B]" donde, en el código J2EE, las instancias de objeto de los métodos tienen un ciclo de vida mayor que el ciclo de vida del servlet analizado, puede realizar hallazgos de regla incorrectos. Por ejemplo, considere el código siguiente:

public void doGet( HttpServletRequest request, HttpServletResponse response ) throws ServletException, IOException {

// Código aquí.... final ServletOutputStream outStream = response.getOutputStream(); //... Ninguna llamada a response.flushBuffer después. }

para el que crea la regla: "Llamar siempre a ServletResponse.flushBuffer() después de ServletResponse.getOutputStream()" Puesto que el objeto de respuesta es una instancia que tiene un ciclo de vida mayor que el del servlet, esto puede originar un problema para el análisis de revisión de código. Puede ver algunos hallazgos en otros servlets que tratan el problema del servlet actual. Tenga en cuenta que la creación de reglas para tales instancias de objeto específicas es cuestionable.

1.11 Positivo falso en la regla definida por el usuario Evitar método de definición

Si crea una regla nueva utilizando la plantilla de regla "Evitar método de definición" y selecciona un método con un nombre totalmente calificado, en la revisión de código solo se utilizan el nombre del método y de los parámetros. El foco de la plantilla de regla está en la firma de los métodos por lo que la información del nombre de clase y el paquete carece de significado.

1.12 Las plantillas que toman un método no funcionan al teclear un nombre de método

Al crear una regla nueva a partir de una plantilla de regla proporcionada, no teclee el nombre de un método. Seleccione el método utilizando el navegador.

1.13 La ventana del error observado aparece al intentar configurar datos de servidor

Cuando esté configurando datos de servidor y aparezca una ventana de error observado, cierre la página correspondiente al archivo .java (código de página) y vuelva a intentar configurar los datos.

Volver al archivo readme principal