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.
In Linux, on the Preferences page, you might not be able to view all the rule categories and rule details when the selected code review contains a large quantity of rules. The workaround for this is to, on the Preference page, select Quick Code review, close the Preferences page, and reopen it. You can then select any code review and have it appear correctly.
Return to the main readme file