Top 5 Java EE Bad Practices Java Developers should Avoid

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. You can further read my article "Don't use System.exit() on Java web application" to learn more about.


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.

If you are new into Java EE world, I suggest you join a hands-on course like The Java EE Course - build a Java EE app from scratch on Udemy to understand the fundamentals and basic guidelines required for creating Java EE application. This will not only prevent you from committing these mistakes but also save a lot of time.

Top 5 Java EE Bad Practices to avoid



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.

Btw, Java EE8 has introduced some new server push technologies, you can see What's New in Java EE 8 to learn more about it.

Top 5 Java EE Bad Practices Java Developers should Avoid



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.


Further Learning
The Java EE Course - build a Java EE app from scratch
What's New in Java EE 8
Java EE with Vaadin, Spring Boot and Maven


Other Java EE articles you may like
  • Top 5 Course to Learn Java EE in 2019 (courses)
  • How to set up a JNDI connection pool in Tomcat? (tutorial)
  • How to send email from a Java Program? (tutorial)
  • How to configure HTTPS on Tomcat server? (tutorial)
  • Data Access Object Design Pattern in Java? (pattern)
  • Difference between JAX-RS and Jersey? (answer)
  • Top 5 blog Java EE developer should follow (blogs)
  • 5 Java EE Online Training Courses for Java Developers (courses)
  • 10 Spring MVC Annotations Java dev should learn (annotations)
  • Top 5 Courses to learn Spring Boot in 2019 (courses)

Thanks for reading this article so far. If you like this article then please share with your friends and colleagues. If you have any questions or feedback then please drop a note.

No comments:

Post a Comment