Friday, April 10, 2020

Top 5 Java EE Bad Practices Java Developers should Avoid

Oracle Java EE, Oracle Java Tutorial and Material, Oracle Java Guides, Oracle Java Cert Exam, Oracle Java Prep

Here are some of the bad coding practices you should avoid while working for a Java EE application or Java Web application in general, which runs on a Web Server like Tomcat or Enterprise Server like JBoss, WebLogic, or IBM WebSphere:

1) Calling System.exit() from a Web application


It is never a good idea for a web application to attempt to shut down the application container. A call to System.exit() is probably part of leftover debug code or code imported from a non-J2EE application.

2) Storing Non-Serializable Object Stored in Session


A Java EE application can make use of multiple JVMs in order to improve application reliability and performance. In order to make the multiple JVMs appear as a single application to the end-user, the Java EE container can replicate an HttpSession object across multiple JVMs so that if one JVM becomes unavailable another can step in and take its place without disrupting the flow of the application.

In order for session replication to work, the values the application stores as attributes in the session must implement the Serializable interface.

Example 1: The following class adds itself to the session, but because it is not serializable, the session can no longer be replicated, and you will see errors in your server log file.

public class DataTransferObject {
   String name;
   String value;

   public void addToSession(HttpSession session) {
     session.setAttribute("dto", this);
   }
}

3) Creating Threads


Thread management in a web application is forbidden by the Java EE standard in some circumstances and is always highly error-prone. Managing threads is difficult and is likely to interfere in unpredictable ways with the behavior of the application container.

Even without interfering with the container, thread management usually leads to bugs that are hard to detect and diagnose like deadlock, race conditions, and other synchronization errors.

4) Socket Based Communication


Socket-based communication in web applications is prone to error. The Java EE standard permits the use of sockets only for the purpose of communication with legacy systems when no higher-level protocol is available. Authoring your own communication protocol requires wrestling with difficult security issues, including:

1. In-band versus out-of-band signaling
2. Compatibility between protocol versions
3. Channel security
4. Error handling
5. Network constraints (firewalls)
6. Session management

Without significant scrutiny by a security expert, chances are good that a custom communication protocol will suffer from security problems.

Many of the same issues apply to a custom implementation of a standard protocol. While there are usually more resources available that address security concerns related to implementing a standard protocol, these resources are also available to attackers.

5) Managing Database Connection instead of Connection Pool


The J2EE standard requires that applications use the container's resource management facilities to obtain connections to resources.

For example, a J2EE application should obtain a database connection as follows:

ctx = new InitialContext();
datasource = (DataSource)ctx.lookup(myDatabaseReference);
conn = datasource.getConnection();

and should avoid obtaining a connection in this way:

conn = DriverManager.getConnection("jdbc://host:port");

Every major web application container provides pooled database connection management as part of its resource management framework. Duplicating this functionality in an application is difficult and error-prone, which is part of the reason it is forbidden under the Java EE standard.

You can also keep a printout of the summary slide to remember these Java EE mistakes and don't repeat or commit in your application.

That's all about some of the Java EE bad practices every Java developer should avoid. Following these advise will not only help you to create a robust Java web application but also will save yours from hours of debugging and troubleshooting because of the unintended consequences of these things.

Related Posts

0 comments:

Post a Comment