J2EE Checklists

A Java J2EE Code Review and best practices checklist is something which a developer or a reviewer should always have in handy and this should be used before getting your code for deployment to production. Security guidelines and checklist are also of importance and should be taken into account before deployment.

Category –Functional Separation

  • Avoid HTML code or presentation logic in Request Handlers
  • Avoid HTML code in EJB’s and any other value objects that the EJB uses
  • It is a good practice to separate the domain objects into Presentation beans and Value Objects
  • Avoid coding business logic in Request Handlers
  • Avoid SQL statements in Session beans except Entity beans
  • Avoid complex java code in JSP’s

Category –Multi-Threading

  • Every call wait() must have corresponding call to notfiy() or notifyAll()
  • Follow Immutable object pattern to provide thread security
  • Do not queue dependent tasks in Thread pools. Execute them linearly
  • Provide timeouts mechanisms when waiting on I/O operations
  • Avoid polling in threads, use wait() – notify() mechanism. Polling is acceptable in case where the thread is waiting on a external event
  • Avoid polling in threads, use wait() – notify() mechanism. Polling is acceptable in case where the thread is waiting on a external event
  • Acquire a set of locks required for a sequence of execution in the same order. This would prevent dead locks

Category – Proper Usage of Inheritance

  • Common methods in the sub-class can be moved to the super-class
  • Avoid unnecessary inheritance. E.g. using inheritance to differentiate various types of class

E.g.

Class Dog {

//methods and variables

}

Class FurryDog extends Dog{ //does nothing}

Class Pomerine extends FurryDog{

//methods and variables

}

Here the FurryDog class does nothing except to identify the Pomerine as a FurryDog. Avoid such inheritance. A common place where the non-conformance occursin Value Objects

Prefer overriding mechanism to using a ‘if-else instanceof’ statement blocks, as overriding makes the code more readable . E.g.

}catch(GeneralException e){

if( e instanceof subEx1)

//doSomething

else if ( e instanceof subEx2)

//do Something

}

Here by moving the //doSomething to GeneralException class and overriding in the subEx1 and subEx2 the instance of check could be avoided

  • Avoid unnecessary overriding i.e. if the sub-class method perform the same function as the super-class overridden method
  • Prefer delegation to deep inheritance i.e. prefer a flat inheritance tree to a deep inheritance tree.

Category – Design Patterns

  • Use Singleton design pattern when only single instance of the class is needed. E.g. all manager type classes.
  • Use Factory pattern to abstract creation of objects.

 a.Abstract factory pattern should be used in case of multiple objects which are similar type

b.Factory pattern if single object

  • Use Façade pattern to separate subsystems
  • Use Proxy pattern to encapsulate Remote objects
  • Use of DataTransfer HashMap pattern to de-couple the clients from EJBs. This pattern should be used only when the EJB may be used outside the scope of the current application

Category – Logging

  • All application should provide 3 logging mechanism

a.Trace Logging

b.Debug logging

c.Production logging

  • All method must have trace logging to enable debugging in production environment
  • Statements acquiring resources such as database connections, socket connections etc. must have debug logs before and after them indicating the status
  • Production logging must be done for all critical errors such as

a.Naming Lookup exceptions

b.Database exceptions

c.Any Exceptions caught at the delegate class level

d.Any Runtime exceptions

e.Any SecurityException

f.Any Exceptions caught at the EJB service level