How to package common code for a J2EE application ?

During development of any J2EE applications, we often run across issues wrt what to do with the common code ?
Should we bundle the common code jar along with the EAR file ? or
Should the common code jar go in the shared library path ?

There are different schools of thought that say we should follow one over the other. Here I will try to list some of the pros and cons of placing the common code in the shared library


1. The development team will deal with only one version of the common code. Had the code been bundled with every application, then dealing with multiple versions becomes a nightmare.

2. Using common code means changes to the underlying framework can be done easily and the change will be effective for al the application in one go.

3. Fixes to the common code automatically apply to all applications.

4. Small amount of memory and hard disk is saved with having only one copy of the common code library.


1. Backward compatibility is paramount. Since every application uses the same version of the common API, it is nearly impossible to coordinate API changes. Thus, the API must be very stable.

2. Changes desired by one application impact all applications. This makes introducing change very difficult. Application teams will have to coordinate their development and test cycles.

3. Fixes required by one application impact all applications. This creates the difficult tradeoff between fixing one application quickly and the risks introduced by the change in other working applications.

4. Code on the lib/ext classpath is not reloadable. Thus, changes to it require restarts of the application servers. Updates to EARs require only a restart of the EAR.

Finally, the team has make a decision, based on the cost benefits analysis of sharing the common code library at runtime.
0 Comments To ' How to package common code for a J2EE application ? '

Post a Comment