The J2EE Best Practices code review consists of one category only; it is also called J2EE Best Practices.
Some rules in the code review require data flow analysis to detect some findings. Data flow analysis traces the path to a finding. Consequently, the code review takes longer to finish when those rules are applied.
The following table lists all of the categories and subcategories in the J2EE Best Practices code review, along with a description of the rules in each one. In the left column, categories are in bold text and subcategories are in plain text.
Category or subcategory | Description |
---|---|
J2EE Best Practices | Contains rules based on the best J2EE development practices and supports Web projects targeted to WebSphere servers |
Correctness | Contains rules to detect incorrect method calls |
Data Race | Contains rules to detect method invocations that can cause data race conditions in J2EE applications |
Garbage Collection | Contains rules to detect method invocations that can delay garbage collection |
Maintainability | Contains rules to detect code that may be hard to maintain in J2EE applications |
Performance and Scalability | Contains rules to detect method invocations that hinder the performance or limit the scalability of a J2EE application |
Resource Management | Contains J2EE best practice rules for using resources in J2EE applications |
The J2EE Best Practices code review applies rules that are of two types: quick rules and deep rules. The characteristics that differentiate the rule types are the length of time the rule takes to be applied and the type of information the rule presents in a finding.
Quick J2EE rules
Quick J2EE rules take less time to be applied in the J2EE Best Practices code review than deep rules require. Quick rules present the same information for a finding as rules in the other code reviews.
Deep J2EE rules
Deep J2EE rules require data flow analysis so they take more time to produce findings than quick rules. Deep J2EE rules not only produce findings, but also show the paths that lead to the findings. These rules require data flow analysis, the method that traces the paths, so they take more time to produce findings than quick rules. Deep rules provide the following additional information:There are 36 deep J2EE rules. The left column of the following table lists the subcategories that contain them. The right column lists or describes which rules in the subcategory are deep J2EE rules.
Category or subcategory | Deep J2EE rule |
---|---|
Correctness | Avoid storing objects that do not implement java.io.Serializable in javax.servlet.http.HttpSession |
Data Race | Avoid assigning to any static fields, from javax.servlet.Service.service(), without using a shared lock Avoid assigning to servlet instance fields, from javax.servlet.Service.service(), without using a shared lock |
Performance and Scalability | Always call javax.servlet.http.HttpSession.invalidate() after javax.servlet.http.HttpServletRequest.getSession() |
Resource Management | All 32 rules in this subcategory are deep J2EE rules. |
This section contains a sample of each rule type that is applied in the J2EE Best Practices code review.
Sample quick rule
The following rule is a sample quick rule that in the Performance and Scalability subcategory.
Avoid calling java.lang.Runtime from any servlet
Sample deep rule
Always call java.io.FileInputStream.close() after new java.io.FileInputStream(java.io.File)
This section documents known issues with the J2EE Best Practices code review.
False positive: An input stream was not closed
Summary: The J2EE Best Practices code review produces a finding that an input stream was not closed. In reality, there is no other input stream to close.
public static int readFirstByte(String fileName) { int firstByte = -1; FileInputStream fis=null; BufferedInputStream bis = null; try { fis = new FileInputStream(fileName); bis = new BufferedInputStream(fis); firstByte = bis.read(); } catch (FileNotFoundException fnfe) { LogUtility.log(fnfe); } catch (IOException ioe) { LogUtility.log(ioe); } finally { if (bis!=null){ try { bis.close(); } catch (IOException ioe){ LogUtility.log(ioe); } } } return firstByte; }
Workaround: Right-click the false-positive finding and click Ignore.
Insufficient information: Finding is reported against a .classpath file
Summary: The J2EE Best Practices code review produces a finding on the .classpath file instead of on a resource in the workbench.
Description: The code review finds a problem with a binary type, and that type has no corresponding resource in the workbench because it is contained in an external JAR.
Reference: RFE RATLC00038795
Workaround:
Resource filters: Do not work for deep rules
Summary: On the Resource Filters page you specify files that you do not want a selected deep rule applied to during a code review. However, the filter does not work and the rule is still applied to the files you specified.
Description: Deep J2EE rules work differently when it comes to specifying files that you do not want a rule applied to during a code review. The deep rules do not recognize files specified on the Resource Filters page, but they do recognize files on the Excluded page, where JAR files are listed by default. These rules recognize two file types to exclude, a fully qualified servlet or JAR file, and ignore all others.