Code Review - release notes


1.0 Known problems
   1.1 User-defined rules cannot include explanations and examples
   1.2 Matches might be removed from the Code Review Details view
   1.3 Cannot create new classes for structural analysis quick fixes
   1.4 Source in certain packages will not be reviewed
   1.5 Line number not always displayed
   1.6 Internal data variables from JSDK or J2EE classes should not appear in the data flow path
   1.7 Can set the depth to negative value on Design Principles / Complexity rules
   1.8 Encoding issue when creating a rule using non-US ASCII characters in its parameters
   1.9 Progress is not properly reported for Structural Analysis rules
   1.10 In main view the Stop/Start button becomes an amalgam
   1.11 Quickfix for rule "Avoid using java.lang.String.compareTo () to compare locale-sensitive strings" proposes incorrect solution
   1.12 Problem with some instanciations of J2EE template rule: Always call [method A] after [method B]
   1.13 Potential problem with J2EE template rule: Always call [methodA] after [methodB]
   1.14 False positive on user-defined Avoid Defining Method rule
   1.15 Templates that take a method do not work when typing in method name
   1.16 Noted error window appears when trying to configure server data
   1.17 Preference page issues under Linux OS

1.0 Known problems

1.1 User-defined rules cannot include explanations and examples

When you create user-defined rules by using the rule templates, you cannot include explanations and examples.

1.2 Matches might be removed from the Code Review Details view

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.

1.3 Cannot create new classes for structural analysis quick fixes

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.

1.4 Source in certain packages will not be reviewed

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

1.5 Line number not always displayed

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.

1.6 Internal data variables from JSDK or J2EE classes should not appear in the data flow path

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.

1.7 Can set the depth to negative value on Design Principles / Complexity rules

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.

1.8 Encoding issue when creating a rule using non-US ASCII characters in its parameters

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.

1.9 Progress is not properly reported for Structural Analysis rules

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.

1.10 In main view the Stop/Start button becomes an amalgam

Occasionally, when starting Code Review, the Start/Stop button shows an icon that is a combination of start and stop.

1.11 Quickfix for rule "Avoid using java.lang.String.compareTo () to compare locale-sensitive strings" proposes incorrect solution

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

1.12 Problem with some instanciations of J2EE template rule: Always call [method A] after [method B]

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.

1.13 Potential problem with J2EE template rule: Always call [methodA] after [methodB]

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.

1.14 False positive on user-defined Avoid Defining Method rule

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.

1.15 Templates that take a method do not work when typing in method name

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.

1.16 Noted error window appears when trying to configure server data

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.

1.17 Preference page issues under Linux OS

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