If you want to write a Java web application, the first thing you’ll need to do is make a difficult decision: choosing the Java application server on which your application will run. This is a tough choice because there are many outstanding ones out there, and the differences between them aren’t always obvious. It’s easy to wind up in a state of analysis-paralysis.
But let’s back up for a second. What are application servers, exactly? Generally speaking, application servers execute Java applications. You launch them in your operating system and then deploy applications into them. Think of application servers as containers that run your Java code and make it functional. In addition, application servers provide some common infrastructure and functional capabilities that you can use in your own code.
In this article, I’ll draw a high-level comparison between the most popular free and open-source Java application servers.
Tomcat is the most popular application server used with Java web applications developed by the Apache Software Foundation. Some sources claim Tomcat’s market share to be more than a whopping 60% of all Java application server deployments.
That’s a lot.
However, there’s a bit of confusion (and even controversy) about Tomcat’s merit as an application server. See, I’m calling it an application server when technically…it isn’t.
Let me explain. Remember when I said that application servers provide some infrastructure and functional capabilities to your application? Well, this set of capabilities isn’t arbitrary. A specification called Java EE precisely defines the functionality of application servers. Therefore, strictly speaking, I should call only the containers that pass Java EE compatibility tests by the name application servers. As of today, Oracle lists three such containers, and Tomcat isn’t one of them.
Oracle has transferred Java EE to the Eclipse Foundation, and it is now called Jakarta EE after Java EE 8. Also, there is a Web Profile subset of the full EE platform now available, as well as a servlet-only web container.
Indeed, Tomcat doesn’t implement all the features required of a Java EE application server. The accurate title for Tomcat would be either “web server” or “servlet container”. But even though Tomcat doesn’t support some Java EE features out of the box, you can still use most of these features. You’ll just need to include them as additional third-party dependencies in your application.
The bottom line is that you can run Java EE applications on Tomcat. I’m guessing you’re looking for a solution and aren’t that interested in terminology intricacies, so I’ll keep calling Tomcat (and later Jetty) an application server to avoid complicating things with too many terms.
So Tomcat is mature, well-documented, and the most widely used Java application server. With good documentation and no shortage of tutorials about it on the internet, Tomcat is a serious contender for the role of application server in almost all Java web applications.
Jetty is another application server (this one developed by Eclipse Foundation) that isn’t technically a fully featured Java EE container. Just like Tomcat, it lacks support for many Java EE features. And just like Tomcat, you can still use most of the features by including additional third-party dependencies.
Even though Jetty’s market share is nowhere near Tomcat’s, it’s still widely used in the industry. Two of its main selling points are its compactness and small footprint. Both make Jetty a great fit for constrained environments and for embedding in other products.
GlassFish is fully featured and certified Java EE application server developed by Oracle. As such, GlassFish is more heavyweight than either Tomcat or Jetty—and, arguably, a bit more difficult to operate.
In fact, GlassFish is more than just a generic Java EE application server. It’s the reference implementation of the Java EE standard. This means that GlassFish is used to showcase Java EE capabilities, and it gets contributions from the same people who define Java EE standards. Therefore, GlassFish will always support the latest Java EE features first. That’s a plus.
The downside of GlassFish is its lack of commercial support. Yes, this article is about free and open-source application servers, but this is still an important point. As your project grows and becomes financially successful, you might be willing to pay to get long-term support, security updates, customer support, etc., for your application server. That’s what commercial support provides, and many companies purchase it. So keep in mind that if you use GlassFish and need commercial support in the future, you’ll need to migrate to a completely different application server.
It might not sound like a big deal to you right now, but it’s a deal-breaker for many businesses. Consider what your future needs might look like, at the very least.
WildFly, formerly known as JBoss Application Server and developed by Red Hat, is another fully featured and certified application server.
The big advantage of WildFly over GlassFish is that Red Hat provides an easy migration path from WildFly to its commercially supported application server called JBoss Enterprise Application Platform. This means that you can use WildFly today and quickly migrate to JBoss EAP in the future to get commercial support if you decide that’s something you need.
Red Hat is also one of the most respected software vendors out there. That says a lot about the company’s policies and customer support. Note: Red Hat was just acquired by IBM for $34 billion, its largest deal ever.
So which Java application server should you use in your own project?
That’s a nuanced question. To be honest, the answer will vary from project to project. That being said, I still want to lay down a general framework that will help you choose.
If your organization already uses a specific application server in other projects, then your best bet would be to stick with that, if possible. Standardization is always a good idea. In addition, the ability to go over to another team and ask for help is invaluable.
That’s the easy case. Now let’s say that doesn’t apply; your organization doesn’t already have a specific application server in use.
If you won’t need Java EE capabilities (e.g., you’re going to use Spring Framework), then I’d say go with Tomcat. It’s the de facto industry standard, and as such, you’ll have the easiest time finding documentation and examples if you choose it. But if you already know you’ll be running your application in a constrained environment, consider choosing Jetty for its smaller footprint.
If you are planning to write a Java EE application, then things become even more nuanced.
As I already said, it’s possible to use Tomcat to run Java EE applications by including third-party dependencies. So if you know that you’ll use just a small subset of Java EE, then Tomcat can still be a good choice. For example: if all you need is JPA implementation, then importing EclipseLink into your project will do and you can happily proceed with Tomcat. However, if you know that you’ll be making a heavy use of Java EE, or that the functionality that you’ll need isn’t available as a third-party plugin, then go with WildFly.
Overall, I’d suggest favoring Tomcat, but consider Jetty if you need its smaller footprint. Otherwise, if you need extensive Java EE support in your project, take WildFly. Most importantly, if your organization already uses a specific application server in other projects, then simply follow suit.
Stackify’s Application Performance Management tool, Retrace, helps improve the performance of your java applications with APM, server health metrics, and error log integration. Start your free, 14 day Retrace trial today.
Stackify's APM tools are used by thousands of .NET, Java, PHP, Node.js, Python, & Ruby developers all over the world.
Explore Retrace's product features to learn more.
If you would like to be a guest contributor to the Stackify blog please reach out to [email protected]
