Révision de code Pratiques recommandées dans J2EE

La révision de code Pratiques recommandées dans J2EE ne comporte qu'une catégorie ; elle est également appelée Pratiques recommandées dans J2EE.

Rôle

La révision de code Pratiques J2EE recommandées applique des règles permettant de détecter les anti-modèles du code difficiles à détecter par des moyens conventionnels. Les anti-modèles sont des problèmes connus qui surviennent dans le code et qui ne respectent pas les pratiques recommandées. Contrairement aux modèles de conception, qui doivent être utilisés, les anti-modèles sont à éviter. Ces anti-modèles peuvent entraîner une baisse importante des performances ou des pannes système. Cette révision de code ne fonctionne que sur les servlets. Ces servlets doivent se trouver dans des projets Web dynamiques destinés à l'un des raccords suivants :
  • WebSphere Application Server 5.0
  • WebSphere Application Server 5.1
  • WebSphere Application Server 6.0
Les JSP, struts et EJB ne sont pas pris en charge.

Certaines règles de la révision de code requièrent une analyse des flux de données permettant de détecter certaines anomalies. L'analyse des flux de données recherche une anomalie dans le chemin. Par conséquent, l'exécution de la révision de code prend un peu plus de temps lorsque ces règles sont appliquées.

Catégories de règles

Le tableau ci-après récapitule toutes les catégories et sous-catégories de la révision de code Pratiques recommandées dans J2EE, ainsi qu'une description des règles de chacune d'elles. Dans la colonne de gauche, les catégories sont en gras et les sous-catégories en texte normal.

Catégorie ou sous-catégorie Description
Pratiques recommandées dans J2EE Contient des règles basées sur les pratiques de développement J2EE recommandées et prend en charge les projets Web destinés aux serveurs WebSphere
Validité Contient des règles permettant de détecter les appels de méthode incorrects
Conflits d'accès aux données Contient les règles permettant de détecter les appels de méthode susceptibles de provoquer des conflits d'accès aux données dans les applications J2EE
Récupération de place Contient les règles permettant de détecter les appels de méthode pouvant retarder la récupération de place
Maintenabilité Contient les règles permettant de détecter les éléments de code dont la maintenance peut s'avérer difficile dans les applications J2EE
Performances et extensibilité Contient les règles permettant de détecter les invocations de méthode qui entravent les performances ou limitent l'extensibilité d'une application J2EE
Gestion des ressources Contient les règles des pratiques recommandées dans J2EE pour l'utilisation de ressources dans des applications J2EE

Types de règle

La révision de code Pratiques J2EE recommandées applique des règles de deux types : les règles rapides et les règles approfondies. Ces types de règle se différencient par leur temps d'exécution et le type d'informations présentées par la règle dans une anomalie.

Règles J2EE rapides

Les règles J2EE rapides prennent moins de temps à appliquer que les règles approfondies dans la révision de code Pratiques J2EE recommandées. Les règles rapides présentent les mêmes informations sur une anomalie que les règles des autres révisions de code.

Règles J2EE approfondies

Les règles J2EE approfondies requièrent une analyse des flux de données et prennent donc plus de temps pour générer les anomalies que les règles rapides. Les règles J2EE approfondies génèrent des anomalies et indiquent les chemins d'accès à ces anomalies. Ces règles requièrent une analyse des flux de données, la méthode qui recherche une anomalie dans les chemins et prennent donc plus de temps pour générer les anomalies que les règles rapides. Les règles approfondies fournissent des informations supplémentaires :

Liste des règles J2EE approfondies

Il existe 36 règles J2EE approfondies. La colonne de gauche du tableau ci-après répertorie les sous-catégories contenant ces règles. La colonne de droite répertorie ou décrit les règles de la sous-catégorie qui correspondent à des règles J2EE approfondies.

Catégorie ou sous-catégorie Règle J2EE approfondie
Validité
Evitez de stocker des objets qui n'implémentent pas
java.io.Serializable dans javax.servlet.http.HttpSession
Conflits d'accès aux données
Evitez d'affecter des valeurs aux champs statiques à partir de
javax.servlet.Service.service() sans utiliser de verrou partagé
Evitez d'affecter des valeurs aux champs d'instance d'un servlet à partir de
javax.servlet.Service.service() sans utiliser de verrou partagé
Performances et extensibilité
Appelez toujours javax.servlet.http.HttpSession.invalidate()	après
javax.servlet.http.HttpServletRequest.getSession()
Gestion des ressources Les 32 règles de cette sous-catégorie correspondent à des règles J2EE approfondies.

Exemples de règle

Cette section contient un exemple de chaque type de règle appliquée dans la révision de code Pratiques J2EE recommandées.

Exemple de règle rapide

La règle suivante est un exemple de règle rapide de la sous-catégorie Performances et extensibilité.

Evitez d'appeler java.lang.Runtime à partir d'un servlet

Exemple de règle approfondie

La règle suivante est un exemple de règle approfondie de la sous-catégorie Gestion des ressources.
Appelez toujours
java.io.FileInputStream.close() après new java.io.FileInputStream(java.io.File)

Incidents connus

Cette section traite des incidents connus liés à la révision de code Pratiques J2EE recommandées.

Faux positif : Un flux en entrée n'a pas été fermé

Récapitulatif : La révision de code Pratiques J2EE recommandées génère une anomalie spécifiant qu'un flux en entrée n'a pas été fermé. En réalité, il n'y a pas d'autre flux en entrée à fermer.

Description : La révision de code ne reconnaît pas que tous les flux en entrée sont fermés dans les cas suivants :
  • Si bis est NULL, il n'y a pas de flux en entrée à fermer
  • Un flux en entrée, FileInputStream, est utilisé pour en créer un second : BufferedInputStream. Lorsque le second flux en entrée est fermé, le premier l'est également.
Illustration : Les lignes mises en évidence dans l'exemple de code suivant illustrent ces deux cas :
public static int readFirstByte(String fileName) {
 int firstByte = -1;
 FileInputStream fis=null;
 BufferedInputStream bis = null;
 try {
  fis = new FileInputStream(fileName);
  bis = new BufferedInputStream(fis);  firstByte = bis.read();
 } catch (FileNotFoundException fnfe) {
  LogUtility.log(fnfe);
 } catch (IOException ioe) {
  LogUtility.log(ioe);
 } finally {
  if (bis!=null){   try {
    bis.close();   } catch (IOException ioe){
    LogUtility.log(ioe);
   }
  }
 }
 return firstByte;
} 

Solution : Cliquez sur l'anomalie faux positif à l'aide du bouton droit de la souris, puis cliquez sur Ignorer.

Informations insuffisantes : Une anomalie est signalée dans un fichier .classpath

Récapitulatif : La révision de code Pratiques J2EE recommandées génère une anomalie dans le fichier .classpath et non dans une ressource du plan de travail.

Description : La révision de code détecte un problème sur un type binaire, mais ce type ne possède pas de ressource correspondante dans le plan de travail car il fait partie d'un fichier JAR externe.

Référence : RFE RATLC00038795

Solution :

  1. Dans la vue Détails de la révision de code, cliquez sur l'onglet Chemins pour voir quel type ne possède pas de ressource correspondante dans le plan de travail.
  2. Développez les informations sur le chemin pour voir les noms des types et éventuellement les méthodes et les zones impliquées dans l'anomalie.

Filtres de ressource : Ne fonctionnent pas pour les règles approfondies

Récapitulatif : Dans la page Filtres de ressource, spécifiez les fichiers auxquels vous ne souhaitez pas appliquer une règle approfondie sélectionnée lors d'une révision de code. Toutefois, le filtre ne fonctionne pas et la règle est quand même appliquée aux fichiers spécifiés.

Description : Les règles J2EE approfondies fonctionnent différemment lorsqu'il s'agit de spécifier des fichiers auxquels vous ne souhaitez pas appliquer une règle lors d'une révision de code. Les règles approfondies ne reconnaissent pas les fichiers spécifiés dans la page Filtres de ressource, mais ils reconnaissent ceux de la page Exclus, dans laquelle les fichiers JAR sont répertoriés par défaut. Ces règles reconnaissent deux types de fichier à exclure, un servlet ou un fichier JAR dont le nom est complet, et ignore tous les autres.

Solution :
  1. Cliquez sur Fenêtre > Préférences pour ouvrir la fenêtre Préférences.
  2. Dans la sous-fenêtre de gauche, développez Java et Révision de code, puis sélectionnez Exclus.
  3. Dans la page Exclus, vérifiez les fichiers répertoriés dans la page Ressources et effectuez l'une des opérations suivantes :
    • Si le fichier à exclure de la révision par les règles J2EE approfondies est répertorié, cliquez sur OK. Aucune autre action n'est requise de votre part.
    • Pour exclure un servlet d'une révision par des règles J2EE approfondies, sélectionnez le fichier .java ou .class du servlet, puis cliquez sur OK.
    • Pour exclure un fichier JAR d'une révision par des règles J2EE approfondies, sélectionnez le fichier JAR, puis cliquez sur OK.
Si un fichier que vous ne souhaitez pas exclure de la révision de code est répertorié, sélectionnez-le et cliquez sur Supprimer.
Conditions d'utilisation | Retours d'informations
(C) Copyright IBM Corporation 2004, 2005. All Rights Reserved.