When you create user-defined rules by using the rule templates, you cannot include explanations and examples.
If you undo the matches found by the rules in the Cyclic Dependencies category, the matches are removed from the Code Review Details view. The matches should not be removed, but should be updated to a status of "Unresolved." To work around this issue, select the rules in the Cyclic Dependencies category and run an analysis of the workspace.
Typically, you can resolve a code issue with a structural analysis quick fix in two ways: 1) select an existing class to which you can move the problematic code, or 2) create a new class to which you can move the problematic code. If you choose the second option, an error prevents the completion of the quick fix.
To work around this issue, create a new class before you apply the quick fix, and select that class in the code review refactoring wizard.
Source contained in the following packages will not be reviewed by some of the J2EE Best Practices rules:
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 the Code Review view, the line number is not always displayed for some of the findings detected by J2EE Best Practices rules. If you double-click the finding, you are taken to the correct line number.
A data flow path shows the dependency history of data changes that lead to a problem that is highlighted by a rule finding. Data flow paths appear on the Path tab. Sometimes data flow paths display internal data structures that are present in JSDK or J2EE classes. For example, rather than saying that a variable of type java.lang.Vector has been modified, you will see that the java.lang.Object[]variable has been modified. This is an internal field from the java.lang.Vector implementation, and it might be confusing to see this private information displayed on the tab.
In the Design Principles rule category, you can set the depth of complexity rules. For example, you can set the rule "Avoid nesting more than 1 class(es)" to "Avoid nesting more than 3 class(es)." For the rule to work correctly, you must use a positive number for the depth. However, complexity rules do not currently ensure that depth is set to a positive number. To avoid this issue, do not enter invalid input such as zero or a negative number.
There is an encoding issue when you create a rule from a template using non-US ASCII characters in its parameters. This happens, for example, when a type or method with local characters is selected. Because of this encoding issue, when rules that are created with these properties and with non-US ASCII characters are run, an exception is generated.
The Code Review progress is not properly reported for Structural Analysis rules (that is, the progress dialog always reports 100% progress). You must wait for the Code Review to finish.
Occasionally, when starting Code Review, the Start/Stop button shows an icon that is a combination of start and stop.
The quickfix for the rule "Avoid using java.langString.compareTo () to compare locale-sensitive strings" proposes two solutions to fix the problem targeted by the rule. The solution that suggests <Use com.ibm.icu.text.Collator> is incorrect. The solution should be <Use java.text.Collator>.
If you create a new rule with the J2EE rule template "Always call [methodA] after [methodB]," when [methodB] is a constructor by default on your workspace, then when the rule is run in a code review, it will not produce any rule findings.
Creating a new rule for a specific object instance from the J2EE best practices template rule: "Always call [methodA] after [methodB]" could produce incorrect rule findings in the next specific case for which you define a rule. If you select methods from the pattern "Always call [methodA] after [methodB]" where, in J2EE code, the object instances of the methods have a life cycle that is greater than the life cycle of the servlet that is being analyzed, you may discover incorrect rule findings. For example, consider the following code:
public void doGet( HttpServletRequest request, HttpServletResponse response ) throws ServletException, IOException {
// Some code here.... final ServletOutputStream outStream = response.getOutputStream(); //... No call to response.flushBuffer after. }
for which you create the rule: "Always call ServletResponse.flushBuffer() after ServletResponse.getOutputStream()" Because the response object is an instance that has a life cycle greater than the servlet itself, this may cause a problem for the code review analysis. You may see some findings in other servlets that target the problem of the current servlet. Note that creating rules for such specific object instances are questionable.
If you create a new rule using the rule template "Avoid Defining Method" and you select a method with a fully qualified name, only the name of the method and parameters are used in code review. The focus of the rule template is on methods signature, so the package and class name information is meaningless.
When you create a new rule from a supplied rule template, do not type in the name of a method. Select the method by using the browser.
When you are configuring server data and a noted error window appears, close the .java file corresponding page (page code) and then retry configuring the data.
Return to the main readme file