Codeprüfung - Release-Informationen


1.0 Bekannte Probleme
   1.1 Benutzerdefinierte Regeln können keine Erläuterungen und Beispiele enthalten
   1.2 Übereinstimmungen werden möglicherweise aus der Sicht für die Codeprüfungsdetails entfernt
   1.3 Für Schnellkorrekturen der Strukturanalyse können keine neuen Klassen erstellt werden
   1.4 Quelle in bestimmten Paketen wird nicht überprüft
   1.5 Zeilennummer wird nicht immer angezeigt
   1.6 Interne Datenvariablen aus JSDK- oder J2EE-Klassen sollten nicht im Datenflusspfad erscheinen
   1.7 Verschachtelungstiefe kann für Designgrundsätze/Komplexitätsregeln auf negativen Wert gesetzt werden
   1.8 Codierungsproblem beim Erstellen einer Regel unter Verwendung von Nicht-US-ASCII-Zeichen in Parametern
   1.9 Verarbeitungsfortschritt wird für Strukturanalyseregeln nicht ordnungsgemäß gemeldet
   1.10 In der Hauptsicht wird der Start/Stopp-Knopf zu einem kombinierten Symbol
   1.11 Schnellkorrektur für die Regel "Avoid using java.lang.String.compareTo () to compare locale-sensitive strings" schlägt falsche Lösung vor
   1.12 Problem mit einigen Instanzierungen der J2EE-Schablonenregel "Always call [method A] after [method B]"
   1.13 Potenzielles Problem mit J2EE-Schablonenregel "Always call [methodA] after [methodB]"
   1.14 Fehlalarm bei benutzerdefinierter Regel zum Vermeiden der Methodendefinierung
   1.15 Schablonen, die eine Methode aufnehmen, funktionieren bei Eingabe des Methodennamens nicht
   1.16 Fenster für erkannten Fehler erscheint beim Versuch, Serverdaten zu konfigurieren

1.0 Bekannte Probleme

1.1 Benutzerdefinierte Regeln können keine Erläuterungen und Beispiele enthalten

Wenn Sie unter Verwendung der Regelschablonen benutzerdefinierte Regeln erstellen, können Sie darin keine Erläuterungen und Beispiele aufnehmen.

1.2 Übereinstimmungen werden möglicherweise aus der Sicht für die Codeprüfungsdetails entfernt

Wenn Sie die Übereinstimmungen widerrufen, die von den Regeln in der Kategorie für zyklische Abhängigkeiten gefunden werden, werden diese Übereinstimmungen aus der Sicht für die Codeprüfungsdetails entfernt. Die Übereinstimmungen sollten nicht entfernt, aber auf den Status "Unaufgelöst" (Unresolved) aktualisiert werden. Wählen Sie als Fehlerumgehung die Regeln in der Kategorie für zyklische Abhängigkeiten aus, und führen Sie dann eine Analyse des Arbeitsbereichs durch.

1.3 Für Schnellkorrekturen der Strukturanalyse können keine neuen Klassen erstellt werden

Normalerweise können Sie ein Codeproblem mit einer Schnellkorrektur der Strukturanalyse auf zwei Arten lösen: 1) Wählen Sie eine vorhandene Klasse aus, in die Sie den problematischen Code versetzen können. 2) Erstellen Sie eine neue Klasse, in die Sie den problematischen Code versetzen können. Wenn Sie die zweite Option wählen, verhindert ein Fehler den Abschluss der Schnellkorrektur.

Erstellen Sie als Fehlerumgehung eine neue Klasse, bevor Sie die Schnellkorrektur anwenden, und wählen Sie diese Klasse im Refactoringassistent für die Codeprüfung aus.

1.4 Quelle in bestimmten Paketen wird nicht überprüft

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

1.5 Zeilennummer wird nicht immer angezeigt

In der Ansicht 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.

1.6 Interne Datenvariablen aus JSDK- oder J2EE-Klassen sollten nicht im Datenflusspfad erscheinen

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.

1.7 Verschachtelungstiefe kann für Designgrundsätze/Komplexitätsregeln auf negativen Wert gesetzt werden

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.

1.8 Codierungsproblem beim Erstellen einer Regel unter Verwendung von Nicht-US-ASCII-Zeichen in Parametern

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.

1.9 Verarbeitungsfortschritt wird für Strukturanalyseregeln nicht ordnungsgemäß gemeldet

Der Verarbeitungsfortschritt der Codeprüfung wird für Strukturanalyseregeln nicht ordnungsgemäß gemeldet (das heißt, der Dialog für den Verarbeitungsfortschritt meldet stets einen Fortschritt von 100 Prozent). Sie müssen warten, bis die Codeprüfung beendet ist.

1.10 In der Hauptsicht wird der Start/Stopp-Knopf zu einem kombinierten Symbol

Gelegentlich wird beim Starten der Codeprüfung durch den Start/Stopp-Knopf ein Symbol angezeigt, das eine Kombination für Start und Stopp darstellt.

1.11 Schnellkorrektur für die Regel "Avoid using java.lang.String.compareTo () to compare locale-sensitive strings" schlägt falsche Lösung vor

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>.

1.12 Problem mit einigen Instanzierungen der J2EE-Schablonenregel "Always call [method A] after [method B]"

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.

1.13 Potenzielles Problem mit J2EE-Schablonenregel "Always call [methodA] after [methodB]"

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.

1.14 Fehlalarm bei benutzerdefinierter Regel zum Vermeiden der Methodendefinierung

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.

1.15 Schablonen, die eine Methode aufnehmen, funktionieren bei Eingabe des Methodennamens nicht

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.

1.16 Fenster für erkannten Fehler erscheint beim Versuch, Serverdaten zu konfigurieren

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.

Zurück zur Readme-Hauptdatei