Hello guys, if you are working in Java EE and creating web applications and enterprise applications then you know that it's not as easy as it looks. You need to know some internal quirks so that your application can work properly in Production. Earlier, I have shared the free courses to learn full-stack Java development, and today, I am going to talk about some coding practices that you should avoid while creating Java web applications or Java EE applications. This will save you a lot of headaches when your application will go live and run in production.
5 Bad Practices to avoid while creating a Java Web application
Without wasting any more of your time, 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 the 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 it.
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.
3. Creating Threads
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 to the 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 a Java EE application. This will not only prevent you from committing these mistakes but also save a lot of time.
4. Socket Based Communication
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 to the 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 a Java EE application. This will not only prevent you from committing these mistakes but also save a lot of time.
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:
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.
5. Managing Database Connection instead of Connection Pool
- In-band versus out-of-band signaling
- Compatibility between protocol versions
- Channel security
- Error handling
- Network constraints (firewalls)
- Session management
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.
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:
and should avoid obtaining a connection in this way:
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 to your application.
That's all about some of the Java EE bad practices every Java developer should avoid. Following this advice will not only help you to create a robust Java web application but also will save you from hours of debugging and troubleshooting because of the unintended consequences of these things.
Other Java EE articles you may like
- Top 5 Course to Learn Java EE for Beginners(courses)
- How to set up a JNDI connection pool in Tomcat? (tutorial)
- How to send emails from a Java Program? (tutorial)
- 7 Best Jakarta EE courses for Developers (best courses)
- How to configure HTTPS on the Tomcat server? (tutorial)
- 10 Best Spring Framework Courses for beginners (spring courses)
- Data Access Object Design Pattern in Java? (pattern)
- 10 Free Spring Boot courses for beginners (free courses)
- Difference between JAX-RS and Jersey? (answer)
- 10 Courses to learn Microservices in Java (online courses)
- 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 for Beginners (courses)
Thanks for reading this article so far. If you like this article then please share it with your friends and colleagues. If you have any questions or feedback then please drop a note.
P. S. - If you are new to the Java EE world and looking for a free online course to start with then you can also check out these free Servlet and JSP courses on Udemy by Ranga Karnam. It's completely free and more than 50K people have already joined this course.
No comments:
Post a Comment
Feel free to comment, ask questions if you have any doubt.