J2EE Best Practices-Codeprüfung

Die J2EE Best Practices-Codeprüfung umfasst nur eine Kategorie, die ebenfalls die Bezeichnung J2EE Best Practices trägt.

Zweck

Die J2EE Best Practices-Codeprüfung wendet Regeln zur Erkennung von Antimustern im Code an, die mit herkömmlichen Methoden nur schwer zu erkennen sind. Antimuster sind bekannte Probleme im Code, die sich nicht an Best Practices orientieren. Während Entwurfsmuster Modelle mit Vorbildcharakter darstellen, sind Antimuster Modelle, die nicht empfehlenswert sind und vermieden werden sollten. Diese Antimuster können zu erheblichen Leistungseinbußen oder zu Systemausfällen führen. Diese Codeprüfung kann nur für Servlets ausgeführt werden. Die Servlets müssen Bestandteil dynamischer Webprojekte sein, die auf eines der folgenden Stubs ausgerichtet sind:
  • WebSphere Application Server 5.0
  • WebSphere Application Server 5.1
  • WebSphere Application Server 6.0
JSPs, Struts und EJBs werden nicht unterstützt.

Bei einigen Regeln der Codeprüfung können bestimmte Ergebnisse nur mit Hilfe einer Datenflussanalyse ermittelt werden. Bei der Datenflussanalyse wird ein Trace für den Pfad durchgeführt, der zu einem Ergebnis führt. Daher dauert die Codeprüfung länger, wenn diese Regeln angewendet werden.

Regelkategorien

Die folgende Tabelle enthält eine Liste aller Kategorien und Unterkategorien der J2EE Best Practices-Codeprüfung sowie eine Beschreibung der Regeln in diesen Kategorien und Unterkategorien. In der linken Spalte werden die Kategorien in Fettdruck und die Unterkategorien in Normaldruck angezeigt.

Kategorie oder Unterkategorie Beschreibung
J2EE Best Practices Enthält Regeln, die auf den Best Practices für die Entwicklung von J2EE-Anwendungen basieren, und unterstützt Webprojekte für WebSphere-Server
Correctness Enthält Regeln zur Ermittlung falscher Methodenaufrufe
Data Race Enthält Regeln zur Ermittlung von Methodenaufrufen, die zu Data-Race-Bedingungen in J2EE-Anwendungen führen können
Garbage Collection Enthält Regeln zur Ermittlung von Methodenaufrufen, die zu einer Verzögerung der Garbage-Collection führen können
Maintainability Enthält Regeln zur Ermittlung von Code, der in J2EE-Anwendungen möglicherweise nur schwer zu verwalten ist
Performance and Scalability Enthält Regeln zur Ermittlung von Methodenaufrufen, durch die die Leistung oder Skalierbarkeit einer J2EE-Anwendung eingeschränkt wird
Resource Management Enthält Regeln auf der Basis der J2EE Best Practices für die Nutzung von Ressourcen in J2EE-Anwendungen

Regeltypen

Die J2EE Best Practices-Codeprüfung wendet zwei Regeltypen an: Regeln für die Schnellprüfung und Regeln für die Komplettprüfung. Die Regeltypen unterscheiden sich im zeitlichen Aufwand für die Anwendung der Regel und in der Art von Informationen, die das Ergebnis der Regelanwendung aufweist.

Regeln für die J2EE-Schnellprüfung

Die Anwendung von Regeln für die J2EE-Schnellprüfung im Rahmen der J2EE Best Practices-Codeprüfung nimmt weniger Zeit in Anspruch als die Anwendung von Regeln für die Komplettprüfung. Regeln für die Schnellprüfung präsentieren in einem Ergebnis dieselben Informationen wie Regeln der übrigen Codeprüfungen.

Regeln für die J2EE-Komplettprüfung

Regeln für die J2EE-Komplettprüfung erfordern eine Datenflussanalyse. Die Ausgabe der Ergebnisse dauert daher länger als bei Regeln für die Schnellprüfung. Regeln für die J2EE-Komplettprüfung erzeugen nicht nur Codeprüfungsergebnisse, sondern zeigen auch die Pfade zu den Ergebnissen an. Diese Regeln erfordern eine Datenflussanalyse. Bei der Datenflussanalyse wird ein Trace für die Pfade durchgeführt. Die Ausgabe der Ergebnisse dauert daher länger als bei Regeln für die Schnellprüfung. Regeln für die Komplettprüfung liefern die folgenden zusätzlichen Informationen:

Liste der Regeln für die J2EE-Komplettprüfung

Es gibt 36 Regeln für die J2EE-Komplettprüfung. In der linken Spalte der folgenden Tabelle sind die Unterkategorien aufgelistet, in denen diese Regeln enthalten sind. Die rechte Spalte enthält Angaben dazu, bei welchen Regeln der Unterkategorie es sich um Regeln für die J2EE-Komplettprüfung handelt.

Kategorie oder Unterkategorie Regel für die J2EE-Komplettprüfung
Correctness
Speichern von Objekten, die nicht java.io.Serializable implementieren, in javax.servlet.http.HttpSession vermeiden
Data Race
Zuordnung zu beliebigen statischen Feldern aus javax.servlet.Service.service() ohne Verwendung einer gemeinsamen Sperre vermeiden
Zuordnung zu Servlet-Instanzenfeldern aus javax.servlet.Service.service() ohne Verwendung einer gemeinsamen Sperre vermeiden
Performance and Scalability
javax.servlet.http.HttpSession.invalidate() immer nach javax.servlet.http.HttpServletRequest.getSession() aufrufen
Resource Management Alle 32 Regeln in dieser Unterkategorie sind Regeln für die J2EE-Komplettprüfung.

Beispielregeln

Dieser Abschnitt enthält ein Beispiel für alle Regeltypen, die im Rahmen der J2EE Best Practices-Codeprüfung angewendet werden.

Beispiel einer Regel für die Schnellprüfung

Die folgende Regel ist ein Beispiel einer Regel für die Schnellprüfung in der Unterkategorie Performance and Scalability.

Aufrufen von java.lang.Runtime aus einem beliebigen Servlet vermeiden

Beispiel einer Regel für die Komplettprüfung

Die folgende Regel ist ein Beispiel einer Regel für die Komplettprüfung in der Unterkategorie Resource Management.
java.io.FileInputStream.close()	immer nach neuem java.io.FileInputStream(java.io.File) aufrufen

Bekannte Probleme

In diesem Abschnitt werden bekannte Probleme bei der J2EE Best Practices-Codeprüfung dokumentiert.

Fehlalarm: Ein Eingabedatenstrom wurde nicht geschlossen

Zusammenfassung: Die J2EE Best Practices-Codeprüfung gibt das Ergebnis aus, dass ein Eingabedatenstrom nicht geschlossen wurde. Tatsächlich gibt es jedoch keinen weiteren Eingabedatenstrom, der geschlossen werden muss.

Beschreibung: Die Codeprüfung erkennt in den folgenden Fällen nicht, dass alle Eingabedatenströme geschlossen sind:
  • Wenn "bis" gleich Null ist, muss kein Eingabedatenstrom geschlossen werden
  • Ein Eingabedatenstrom, FileInputStream, wird zum Erzeugen eines weiteren Eingabedatenstroms, BufferedInputStream, verwendet. Beim Schließen des zweiten Eingabedatenstroms wird auch der erste Eingabedatenstrom geschlossen.
Veranschaulichung: Die hervorgehobenen Linien im folgenden Codebeispiel veranschaulichen die beiden Fälle:
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;
} 

Problemumgehung: Klicken Sie mit der rechten Maustaste auf das fehlerhafte Ergebnis, und klicken Sie dann auf Ignorieren.

Keine ausreichenden Informationen: Das ausgegebene Ergebnis bezieht sich auf eine .classpath-Datei.

Zusammenfassung: Die J2EE Best Practices-Codeprüfung gibt ein Ergebnis aus, das sich auf die classpath-Datei statt auf eine Ressource der Workbench bezieht.

Beschreibung: Die Codeprüfung ermittelt ein Problem des Typs Binär, zu dem keine entsprechende Ressource in der Workbench existiert, da sich der Typ in einer externen JAR-Datei befindet.

Referenz: RFE RATLC00038795

Problemumgehung:

  1. Klicken Sie in der Sicht Codeprüfung - Details auf die Registerkarte Pfade, um den Typ zu ermitteln, für den keine entsprechende Ressource in der Workbench existiert.
  2. Blenden Sie alle Pfadinformationen ein, um die Namen der Typen sowie gegebenenfalls die Namen der Methoden und Felder anzuzeigen, die für das Ergebnis relevant sind.

Ressourcenfilter: Können bei Regeln für die Komplettprüfung nicht angewendet werden

Zusammenfassung: Auf der Seite "Ressourcenfilter" geben Sie Dateien an, auf die eine bestimmte Regel für die Komplettprüfung im Rahmen der Codeprüfung nicht angewendet werden soll. Der Filter funktioniert jedoch nicht, so dass die Regel dennoch auf die angegebenen Dateien angewendet wird.

Beschreibung: Regeln für die J2EE-Komplettprüfung weisen ein anderes Verhalten auf, wenn Sie Dateien angeben, auf die eine Regel bei einer Codeprüfung nicht angewendet werden soll. Auf der Seite "Ressourcenfilter" angegebene Dateien werden von den Regeln für die Komplettprüfung nicht erkannt, wohl aber Dateien auf der Seite "Ausgeschlossen", auf der JAR-Dateien standardmäßig aufgelistet werden. Diese Regeln erkennen zwei auszuschließende Dateiformate, eine vollständig qualifizierte Servlet- oder JAR-Datei, und ignorieren alle sonstigen Formate.

Problemumgehung:
  1. Klicken Sie auf Fenster > Benutzervorgaben, um das Fenster "Benutzervorgaben" zu öffnen.
  2. Blenden Sie im linken Teilfenster Java und Codeprüfung ein, und wählen Sie Ausgeschlossen aus.
  3. Prüfen Sie auf der Seite "Ausgeschlossen" die auf der Ressourcenseite aufgelisteten Dateien, und führen Sie dann einen der folgenden Schritte aus:
    • Wenn die Datei aufgelistet wird, die von der Prüfung anhand von Regeln für die J2EE-Komplettprüfung ausgeschlossen werden soll, klicken Sie auf OK. Weitere Schritte Ihrerseits sind nicht erforderlich.
    • Wenn ein Servlet von der Prüfung anhand von Regeln für die J2EE-Komplettprüfung ausgeschlossen werden soll, wählen Sie die .java- oder .class-Datei des Servlets aus und klicken auf OK.
    • Wenn eine JAR-Datei von der Prüfung anhand von Regeln für die J2EE-Komplettprüfung ausgeschlossen werden soll, wählen Sie die JAR-Datei aus und klicken auf OK.
Wenn eine Datei aufgelistet wird, die nicht von der Codeprüfung ausgeschlossen werden soll, wählen Sie die Datei aus und klicken auf Entfernen.