Die in den folgenden Paketen enthaltene Quelle wird von einigen der J2EE-Regeln für empfohlene Methoden nicht geprüft:
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
In der Sicht für Codeprüfung (Code Review) wird für einige Fundstellen der J2EE-Regeln für empfohlene Methoden nicht immer die Zeilennummer angezeigt. Wenn Sie die Fundstelle doppelt anklicken, werden Sie zu der korrekten Zeilennummer geführt.
Ein Datenflusspfad zeigt das Abhängigkeitsprotokoll von Datenänderungen, die zu einem Problem führen, welches durch eine Regelfundstelle hervorgehoben ist. Datenflusspfade erscheinen unter der Registerkarte 'Pfad'. Manchmal zeigen Datenflusspfade interne Datenstrukturen an, die in JSDK- oder J2EE-Klassen vorhanden sind. Man würde dann beispielsweise nicht sagen, dass eine Variable des Typs java.lang.Vector geändert wurde. Stattdessen würde man sehen, dass java.lang.Object[]variable geändert wurde. Dies ist ein internes Feld aus der Implementierung java.lang.Vector, und die Anzeige dieser privaten Informationen auf der Registerkarte könnte verwirrend sein.
In der Kategorie der Designgrundsatzregeln können Sie die Verschachtelungstiefe von Komplexitätsregeln festlegen. Sie können zum Beispiel die Regel "Avoid nesting more than 1 class(es)" (Verschachtelung von mehr als 1 Klasse(n) vermeiden) auf "Avoid nesting more than 3 class(es)" (Verschachtelung von mehr als 3 Klasse(n) vermeiden) festlegen. Damit die Regel korrekt ausgeführt wird, müssen Sie für die Verschachtelungstiefe eine positive Zahl verwenden. Die Komplexitätsregeln stellen gegenwärtig jedoch nicht sicher, dass die Verschachtelungstiefe auf eine positive Zahl gesetzt ist. Um dieses Problem zu vermeiden, geben Sie keinen ungültigen Wert wie z. B. null oder eine negative Zahl ein.
Ein Codierungsproblem tritt auf, wenn Sie eine Regel aus einer Schablone mit Nicht-US-ASCII-Zeichen in den Parametern erstellen. Das passiert zum Beispiel, wenn ein Typ oder eine Methode mit lokalen Zeichen ausgewählt ist. Auf Grund dieses Codierungsproblems wird eine Ausnahmebedingung generiert, wenn eine mit diesen Eigenschaften und mit Nicht-US-ASCII-Zeichen erstellte Regel ausgeführt wird.
Der Verarbeitungsfortschritt der Codeprüfung wird für die Regeln der Strukturanalyse nicht ordnungsgemäß berichtet (der Fortschrittsdialog berichtet immer einen Verarbeitungsfortschritt von 100%). Sie müssen warten, bis die Codeprüfung fertig gestellt ist.
Gelegentlich wird beim Starten der Codeprüfung durch den Start/Stopp-Knopf ein Symbol angezeigt, das eine Kombination für Start und Stopp darstellt.
Die Schnellkorrektur für die Regel "Avoid using java.langString.compareTo () to compare locale-sensitive strings" schlägt zwei Lösungen für das Problem vor, die das Ziel der Regel darstellt. Der Lösungsvorschlag <Use com.ibm.icu.text.Collator> ist nicht korrekt. Die Lösung muss lauten: <Use java.text.Collator>.
Wenn Sie eine neue Regel erstellen mit der J2EE-Regelschablone "Always call [methodA] after [methodB]" und [methodB] ein Konstruktor in Ihrem Workspace ist, wird die Regel bei Ausführung in einer Codeprüfung keine Regelfundstellen generieren.
Beim Erstellen einer neuen Regel für eine bestimmte Objektinstanz mit Hilfe der J2EE-Best Practices-Schablonenregel "Always call [methodA] after [methodB]" könnten in dem nächsten spezifischen Fall, für den Sie die Regel erstellen, falsche Fundstellen generiert werden. Wenn Sie Methoden aus dem Muster "Always call [methodA] after [methodB]" auswählen und (im J2EE-Code) die Objektinstanzen der Methoden einen längeren Lebenszyklus haben als das analysierte Servlet, stellen Sie unter Umständen falsche Regelfundstellen fest. Ziehen Sie beispielsweise folgenden Code in Betracht:
public void doGet( HttpServletRequest request, HttpServletResponse response ) throws ServletException, IOException {
// Some code here.... final ServletOutputStream outStream = response.getOutputStream(); //... No call to response.flushBuffer after. }
Für diesen erstellen Sie die Regel: "Always call ServletResponse.flushBuffer() after ServletResponse.getOutputStream()". Da das Antwortobjekt eine Instanz ist, die einen längeren Lebenszyklus hat als das Servlet selbst, kann dies zu einem Problem für die Codeprüfungsanalyse führen. Möglicherweise sehen Sie einige Fundstellen anderer Servlets, die das gleiche Problem wie das des aktuellen Servlets darstellen. Beachten Sie, dass das Erstellen von Regeln für solche spezifischen Objektinstanzen bedenklich ist.
Wenn Sie eine neue Regel unter Verwendung der Regelschablone "Avoid Defining Method" erstellen und eine Methode mit einem vollständig qualifizierten Namen auswählen, wird nur der Name der Methode und Parameter in der Codeprüfung verwendet. Der Fokus der Regelschablone liegt auf der Methodensignatur. Die Paket- und Klassennameninformationen sind nicht von Bedeutung.
Wenn Sie mit Hilfe einer bereitgestellten Regelschablone eine neue Regel erstellen, geben Sie nicht den Namen einer Methode ein. Wählen Sie die Methode mit Hilfe des Browsers aus.
Wenn beim Konfigurieren der Serverdaten das Fenster für einen festgestellten Fehler erscheint, schließen Sie die entsprechende Seite der .java-Datei (Seitencode), und versuchen Sie anschließend erneut, die Daten zu konfigurieren.