J2EE Best Practices code review

The J2EE Best Practices code review consists of one category only; it is also called J2EE Best Practices.

Purpose

The J2EE Best Practices code review applies rules to detect antipatterns in the code that are very hard to detect by conventional means. Antipatterns are known problems that occur in code and do not follow best practices. While design patterns are good models to follow, anti-patterns are bad models that you should avoid. These antipatterns can cause serious performance degradation or system outages. This code review runs on servlets only. The servlets must be in dynamic Web projects targeted to one of the following stubs:
  • WebSphere® Application Server 5.0
  • WebSphere Application Server 5.1
  • WebSphere Application Server 6.0
JSPs, struts, and EJBs are not supported.

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.

Rule categories

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

Rule types

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:

List of deep J2EE rules

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.

Sample 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

The following rule is a sample deep rule that is in the Resource Management subcategory.
Always call java.io.FileInputStream.close() after new java.io.FileInputStream(java.io.File)

Known issues

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.

Description: The code review does not recognize that all input streams are closed in the following situations:
  • If bis is null, then there is no input stream to close
  • One input stream, FileInputStream, is used to create a second one, BufferedInputStream. When the second input stream closes so does the first one.
Illustration: The highlighted lines in the following code example illustrate both situations:
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:

  1. In the Code Review Details view, click the Paths tab to see which type does not have a corresponding resource in the workbench.
  2. Expand the path information to see the names of the types, and possibly methods and fields, involved in the finding.

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.

Workaround:
  1. Click Window > Preferences to open the Preferences window.
  2. In the left pane, expand Java™ and Code Review, then select Excluded.
  3. On the Excluded page, review the files listed on the Resources page and do one of the following:
    • If the file you want to exclude from being reviewed by deep J2EE rules is listed, click OK. No further action is required on your part.
    • To exclude a servlet from being reviewed by deep J2EE rules, select the servlet’s .java or .class file and then click OK.
    • To exclude a JAR file from being reviewed by deep J2EE rules, select the JAR file and then click OK.
If a file is listed that you do not want excluded from the code review, select the file and click Remove.
Feedback
(C) Copyright IBM Corporation 2004, 2005. All Rights Reserved.