JAVA/J2EE coding/architectural Best Practices for Enterprise Application Development - By Keshav Tripathy, Nirmalya Labs

JAVA/J2EE coding/architectural standard for Enterprise Application Development - By Keshav Tripathy

Developing bespoke enterprise application using Java/J2EE requires enormous understanding of the business domain as well as greater understanding of the J2EE framework, Java language and most importantly solid software engineering principles. Using coding standards is extremely important which makes code more consistent, easy to debug and easy to maintain. 

Here is an experiential based recommendation on JAVA coding and architectural standards, one which was used effectively in one of the largest Enterprise Application Development efforts. The size of development includes more than 100 professionals working for almost 18 months. The below prescribed coding standard was used in the mentioned application development and resulted in a robust code and also led to the proverbial "do it right first time" expectations. Errors were minimal, every body wrote their code following the standard. The result was the whole application code so manageable. 

We have developed our own Java/J2EE best practices at Nirmalya Labs.

Here it goes from a real project from the real leader:

Coding / Architectural standards

Java files

1.Tracers :

a. Should be used for debugging purpose only.

b. Before the code is Checked – in , make sure to remove all the unnecessary tracers. Remember, each method call on the Tracer object will have impact on performance, though the tracers are kept off .

2.Strings / StringBuffers :

a. Use StringBuffer, instead of Strings … where ever lot of String operations are needed such as concatenation etc.

b. Always try to use String literals instead of String objects. When we create a String without the new operator and if the content already exists it uses a single instance of the literal instead of creating a new object every time.

Eg. String str1 = "Hello I am here "; //String literal

String str2= "Hello I am here "; //String literal

String str3 = new ("Hello I am here "); //String Object

3.Exceptions :

a. Catch all the possible Exceptions.

b. All the RuntimeExceptions should be caught in the application tier.

They may be wrapped into a usecase specific exception.

c. Do not catch the Exceptions in the loops. Instead, use the loops inside

a try-catch block.

d. When using method calls always handle the exceptions in the method where they occur, do not allow them to propagate to the calling method unless it is specifically required. It is efficient to handle them locally since allowing them to propagate to the calling method takes more execution time.

4.Loops :

 a. Avoid usage of nested loops to the extent possible.

b. Avoid using method calls in loops for termination condition this is costly instead use a temporary variable and test the loop termination with the temporary variable.

Eg : instead of for(a=0;a

Use int size = Obj.getSize();

for(a=0;a

c. Avoid the usage of nested loops.

d. Use switch case statements, instead of multiple if / if-else statements.

e. Avoid object creation in loops.

5.HttpSession :

a. Optimize the session data. Do not over load the HttpSession data, as this will impact the session replication time over the clustered environment.

6.DataBase calls :

a. The application should be making the DB calls from the app tier only.

b. Restrict the application to single call per transaction . If the logic asks for multiple calls, then check the possibility of having a stored procedure, which can do the same job in one call from the application.

c. Avoid DB calls from web tier.

d. Optimize the usage of BusinessTransaction class and release the connection after use.

e. Use the finally block to release the resources such as DB connection.

f. Use PreparedStatement of Business Transaction Object than the execute method. It will increase the performance significantly.

g. Optimize the DB queries.

7.Unused Objects : Nullify the unused object in the helper and other Objects.

8.Middleware / Database Calls : Make sure that no transaction will have more that ONE DB/middleware call.

9.Configuration Data : Be wise enough while storing the data in configuration cache as it consumes time to load. Keep the unchanged Constant data in the Java Constants File.

JSPs

1. Presence of embedded JS in JSP/HTML/JS

This is of high risk in nature. As part of this we need to focus on the following  The JSP should not have any definition of JS functions. All the JavaScript functions should be defined in a separate JS file.   We may call the function in the JSP and pass the variables ( if needed ).

2. Browser buffer requests: If any JSP is using this page directive, that is an indicative of huge output generation. Need to verify, if we can reduce those pages content wise.

 Eg : A large chunk of data may be written through a JS function and the same may be called here. This way the JS is cached in browser and the net bandwidth will be reduced. OR may be a style sheet be used.

3. Comments in Javascript :Optimize the single line and multi line comments in JavaScript files.Because, the more the commented lines ... the same is the impact on bandwidth.

4. Duplicate Javascript function blocks within a file:Try to identify the duplicate functions and remove them. Make the necessary changes in corresponding calling pages.

5. HTML Tags: a. Optimize the use of tables. May be JS function can present the data in the form of a table by accepting the required variables. Hence, this will be a method call from JSP and so the reduction in bandwidth. Also, the JS is cached in browser. This also gives the flexibility of changing the presentation, if required ... with out touching the JSP.

 b. Remove the white spaces in JSP / HTMLs.

 c. Remove the empty blocks of HTML tags. Eg: Empty DIVs, Empty TABLE tags etc.

6. Use of Java code in JSP

Removal of Java code from JSPs, where the Java is doing the validations/business logic

checks etc. Instead, move this to a method in a Java class, may be an Action Class.

7. CSS info

Do not code any style related classes in JSPs/HTML. Instead, use a CSS file.

8. Frames / Iframes

Avoid using Frames and Iframes extensively. Also, while refreshing the page, refresh the necessary frame only ( in the case of using frames ).

9. Conclusion

 In a nutshell, A JSP must be used for the purpose of displaying the information ONLY. It should not contain any business logic and calls to database etc

   Comment    30-06-2017 10 : 50 AM