Vérification du code - Notes sur l'édition


1.0 Incidents connus
   1.1 La source de certains packages ne sera pas vérifiée
   1.2 Le numéro de ligne n'est pas toujours affiché
   1.3 Les variables des données internes des classes JSDK ou J2EE ne doivent pas apparaître dans le chemin du flux de données
   1.4 Il est possible d'affecter une longueur négative dans les règles Principes de conception/Complexité
   1.5 Incident de codage lors de la création d'une règle dont les paramètres contiennent des caractères ASCII non anglais
   1.6 La progression des règles de l'analyse structurelle n'est pas correctement indiquée
   1.7 Dans la vue principale, le bouton Démarrer/Arrêter devient un amalgame
   1.8 Le correctif rapide de la règle "Evitez d'utiliser java.lang.String.compareTo () pour comparer des chaînes qui dépendent de l'environnement local" propose une solution incorrecte
   1.9 Incident dans certaines instanciations de la règle de modèle J2EE : Appelez toujours [méthode A] après [méthode B]
   1.10 Incident possible dans la règle de modèle J2EE : Appelez toujours [méthode A] après [méthode B]
   1.11 Valeur positive erronée dans la règle "Evitez de définir la méthode" définie par l'utilisateur
   1.12 Les modèles qui utilisent une méthode ne fonctionnent pas lorsque vous saisissez le nom de la méthode
   1.13 La fenêtre des erreurs signalées apparaît lors de la tentative de configuration des données du serveur

1.0 Incidents connus

1.1 La source de certains packages ne sera pas vérifiée

La source contenue dans les packages suivants ne sera pas vérifiée par certaines des règles Pratiques recommandées dans 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 Le numéro de ligne n'est pas toujours affiché

Dans la vue Révision de code, le numéro de ligne n'est pas toujours affiché pour certaines des occurrences détectées par les règles internes. Si vous cliquez deux fois sur l'occurrence, vous accédez au numéro de ligne approprié.

1.3 Les variables des données internes des classes JSDK ou J2EE ne doivent pas apparaître dans le chemin du flux de données

Un chemin de flux de données montre l'historique des dépendances des modifications de données ayant entraîné un incident mis en évidence par une recherche de règle. Les chemins de flux de données apparaissent dans la page Chemin. Les chemins de flux de données affichent parfois les structures de données internes des classes JSDK ou J2EE. Par exemple, au lieu d'un message indiquant qu'une variable de type java.lang.Vector a été modifiée, vous verrez un message spécifiant que la variable java.lang.Object[] a été modifiée. Il s'agit d'une zone interne à l'implémentation de java.lang.Vector et l'affichage de ces informations privées dans la page peut être déconcertant.

1.4 Il est possible d'affecter une longueur négative dans les règles Principes de conception/Complexité

Dans la catégorie de règles Principes de conception, vous pouvez définir la longueur des règles de complexité. Par exemple, vous pouvez remplacer la règle "Evitez d'imbriquer plus de 1 class(es)" par "Evitez d'imbriquer plus de 3 class(es)." Pour que la règle fonctionne correctement, vous devez utiliser une longueur positive. Toutefois, les règles de complexité ne vérifient pas que vous avez bien affecté un nombre positif à la règle. Pour éviter cet incident, n'entrez pas de valeur non valide, telle qu'un zéro ou un nombre négatif.

1.5 Incident de codage lors de la création d'une règle dont les paramètres contiennent des caractères ASCII non anglais

Un incident de codage survient lorsque vous créez une règle à partir d'un modèle dont les paramètres contiennent des caractères ASCII non anglais. Cela se produit, par exemple, si un type ou une méthode contenant des caractères locaux est sélectionné. En raison de cet incident de codage, lorsque des règles créées avec ces propriétés et des caractères ASCII non anglais sont exécutées, une exception est générée.

1.6 La progression des règles de l'analyse structurelle n'est pas correctement indiquée

La progression de la révision du code n'est pas correctement signalée pour les règles de l'analyse structurelle (la boîte de dialogue de progression affiche toujours une progression de 100 %). Vous devez attendre la fin de la révision du code.

1.7 Dans la vue principale, le bouton Démarrer/Arrêter devient un amalgame

Parfois, lorsque vous lancez la vérification du code, le bouton Démarrer/Arrêter affiche une icône représentant une combinaison de démarrer et arrêter.

1.8 Le correctif rapide de la règle "Evitez d'utiliser java.lang.String.compareTo () pour comparer des chaînes qui dépendent de l'environnement local" propose une solution incorrecte

Le correctif rapide de la règle "Evitez d'utiliser java.langString.compareTo () pour comparer des chaînes qui dépendent de l'environnement local" propose deux solutions pour résoudre l'incident ciblé par la règle. La solution recommendant d'<utiliser com.ibm.icu.text.Collator> est incorrecte. Vous devez <utiliser java.text.Collator>.

1.9 Incident dans certaines instanciations de la règle de modèle J2EE : Appelez toujours [méthode A] après [méthode B]

Si vous créez une règle à l'aide du modèle de règle J2EE "Appelez toujours [méthode A] après [méthode B]" et que [méthode B] correspond à un constructeur par défaut dans votre espace de travail, lorsque la règle est exécutée dans une vérification de code, aucune occurrence de règle n'est générée.

1.10 Incident possible dans la règle de modèle J2EE : Appelez toujours [méthode A] après [méthode B]

Si vous créez une règle pour une instance d'objet spécifique à partir du modèle de règle Pratiques recommandées dans J2EE : "Appelez toujours [méthode A] après [méthode B]", les occurrences de règle générées risquent d'être incorrectes dans le prochain cas pour lequel vous définissez une règle. Si vous sélectionnez des méthodes du modèle "Appelez toujours [méthode A] après [méthode B]" dans lequel, en code J2EE, les instances d'objet des méthodes ont un cycle de vie supérieur à celui du servlet analysé, les occurrences de règle détectées risquent d'être incorrectes. Prenons par exemple le cas du code suivant :

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

// Du code ici... final ServletOutputStream outStream = response.getOutputStream(); //... Aucune appel à response.flushBuffer après. }

Vous créez pour ce code la règle suivante : "Appelez toujours ServletResponse.flushBuffer() après ServletResponse.getOutputStream()". L'objet de réponse étant une instance dont le cycle de vie est supérieur à celui du servlet, l'analyse de la vérification du code peut poser des difficultés. Vous risquez de trouver dans d'autres servlets des occurrences qui ciblent l'incident du servlet actuel. Notez que la création de règles pour ces instances d'objet spécifiques est discutable.

1.11 Valeur positive erronée dans la règle "Evitez de définir la méthode" définie par l'utilisateur

Si vous créez une règle à l'aide du modèle de règle "Evitez de définir la méthode" et que vous sélectionnez une méthode avec un nom complet, seuls le nom de la méthode et les paramètres sont utilisés dans la vérification du code. Le modèle de règle s'intéresse surtout à la signature des méthodes ; les informations relatives au nom du package et de la classe ne lui sont d'aucune importance.

1.12 Les modèles qui utilisent une méthode ne fonctionnent pas lorsque vous saisissez le nom de la méthode

Lorsque vous créez une règle à partir d'un modèle de règle fourni, n'entrez pas le nom d'une méthode. Sélectionnez la méthode à l'aide du navigateur.

1.13 La fenêtre des erreurs signalées apparaît lors de la tentative de configuration des données du serveur

Lorsque vous configurez les données du serveur et qu'une fenêtre d'erreurs signalées apparaît, fermer la page correspondant au fichier .java (code de page), puis réessayez de configurer les données.

Retour au fichier Readme principal