The main problem with a Tomcat vs. Jetty comparison stems from the fact that there are more similarities between the two Java application servers than there are differences. For example:
- Tomcat and Jetty are both open source;
- Tomcat and Jetty are both written in Java;
- Tomcat and Jetty both implement the Servlet and JSP specification;
- Tomcat and Jetty are both widely used in production environments; and
- Tomcat and Jetty both enjoy widespread and passionate community support.
As you can see, a Jetty vs. Tomcat comparison isn't a straightforward task.
Differences between Jetty and Tomcat
Jetty predates Tomcat by four years, with its original release in 1995. Of course, Jetty couldn't be considered a Java-based server back in 1995, as Java itself wasn't released until 1996. As you can imagine, both Jetty and Tomcat servers have evolved significantly since their earliest days, with their move towards a pure Java-based implementation at the forefront.
Another big difference between Jetty and Tomcat is their organizational allegiance. Tomcat is an Apache project, while Jetty is managed by the Eclipse Foundation. In terms of licensing, Tomcat enjoys the Apache 2.0 open source license, while Jetty is dual licensed through both the Apache 2.0 License and the Eclipse Public License 1.0.
|Tomcat vs. Jetty: The key differences|
|Purveyor||Eclipse Foundation||Apache Software Foundation|
|License||Apache License 2.0 and
Eclipse Public License 1.0
|Apache License 2.0|
|High profile clients||Yahoo, Google, Apache Geronimo||Spring, JBoss, Jenkins CI|
|Logo||Jetty command prompt||An adult male cat|
|Market share||8-12%||Greater than 50%|
|Industry perception||Performance focused||Specification focused|
In terms of market share, Apache Tomcat dominates. A 2017 Plumbr application survey found that Tomcat was used by 63% of respondents, while Jetty was used by only 9%. In past Java trends surveys performed by TheServerSide, similar numbers were bore out, with Tomcat above 50% market penetration, and Jetty hovering between 8 and 12%.
Both Tomcat and Jetty are formidable servers capable of withstanding enterprise workloads, and because of that, many recognizable players in the IT industry build systems upon them.
The popular Spring framework built their flagship tc_Server -- now known as the Pivotal tc Server -- on Tomcat, and Tomcat is the default embedded server when you create a Spring Boot microservice. With that said, it only takes few quick changes to a Maven POM file to replace Tomcat with Jetty in a Spring Boot deployment.
Also worth noting is that Tomcat is used as the default web container for the fully Java EE compatible JBoss application server.
Eclipse Jetty isn't short of an impressive list of bona fides, either. The Yahoo Hadoop Cluster, Google AppEngine, Apache Geronimo, GWT and even the standalone Jenkins CI server are all powered by Jetty.
Java EE web profile support
While both Jetty and Tomcat support JavaServer Pages, the Servlet API and Java WebSockets, neither of them fully support the Java EE web profile, which requires support for APIs such as JTA, JPA and JSF.
If you want support for these additional technologies, it's fairly easy to integrate individual Java EE web profile APIs into these servers. For example, if you install Mojarra it will provide JSF support, while a Weld configuration will provide support for contexts and dependency injection. But these features are not available to Jetty and Tomcat out of the box.
It is worth noting that the Apache TomEE project -- which is built on top of Apache Tomcat -- does indeed provide a prepackaged, fully certified implementation of the Java EE 6 web profile. There is no equivalent Eclipse project that provides a certified web profile for Jetty.
Tomcat vs. Jetty specification support
One of the key Tomcat vs. Jetty differences is their approach on updated specification implementations. Apache Tomcat tends to pride itself on quickly supporting the latest implementation of supported specifications such as the Servlet and JSP API. Jetty, on the other hand, tends to plan its development efforts based on demands from users.
Greg WilkinsJetty Project Leader, Eclipse Foundation
For example, the Servlet 4.0 specification was finalized in the third quarter of 2017. With the January 2018, 9.0 release, Tomcat boasted implementation support. In contrast, Jetty support for version 4.0 of the servlet specification won't appear until 2020 with the version 10 release.
This may sound like a strike against Jetty, but don't be so quick to judge. The Servlet 4.0 specification didn't introduce any earth-shattering advancements over the previous release, and the Eclipse community simply felt development would be better spent focused on user-requested features, rather than chasing a version of the Servlet API that nobody used.
Tomcat vs. Jetty performance
Performance is always a difficult topic to discuss and compare, as performance tests can be flawed in many indiscernible ways. Furthermore, performance might be tested in a way that's not consistent with the way a given client might be interested in using the product. A performance test might not be indicative or representative of how a product would behave in a specific environment.
With that said, Jetty has always made startup time reductions and server footprint minimization high priorities. Jetty is highly modular, and applications can be deployed to scaled-back versions of Jetty with only a minimal set of supporting JARs. Minimal deployments like these have become increasingly popular as microservices deployments become the norm.
In the TechEmpower JSON serialization benchmark, frameworks that use Jetty rank much higher than those that use Tomcat. Jetty appears first in the 81st position, while Tomcat doesn't appear until the 145th, a point at which several other frameworks that use Jetty already appear.
This result could simply reflect the fact that Jetty is popular among those in the Java community who place a great influence on performance, as opposed to the fact that Jetty itself was indeed faster than Tomcat. After all, many factors go into these tests. But there is no doubt that Jetty is popular with those in the industry that prioritize performance.
Jetty vs. Tomcat: Which to choose?
The choice between Jetty and Tomcat is a difficult decision to advise others on.
Personally, I have a long history with Tomcat. I also do a significant amount of work with Spring, and I like playing around with the latest version of an API, if only to review it. That tends to push me in the direction of Tomcat when choosing between Servlet containers.
I also like the large Tomcat user base, which offers a great deal of support for the product in online forums. But popularity itself isn't a good reason for a given product to remain popular.
I have a personal bias that makes me lean towards Tomcat. I lean even more towards WebSphere, but that's a sin I will absolve myself of in another application server comparison article.
I will say that the more I use Jetty, the more impressed I am with it. And if I was seriously into application performance or was looking at large-scale microservices development, I would likely be swayed away from Tomcat.
Both Google and Yahoo have invested in Jetty for use in projects that place a great deal of importance on startup time and runtime responsiveness. Who am I to second-guess the engineers that back those companies? If performance is one of my most important, non-functional requirements, I'd likely be a proponent of Jetty.
The fact is, regardless of which side you take in the Tomcat vs. Jetty comparison, you really can't make a bad decision. Both are widely used and have proven themselves in large-scale deployments. These two products are part of an endless bounty of open source riches that the server-side Java community is very lucky to have.
The difference between Tomcat vs Jetty
On whole, the key difference between Tomcat and Jetty is the fact that Apache Tomcat places great stress on being up to date with the latest specification, while Eclipse Jetty prioritizes the needs of their user community which tends to result on an emphasis on performance.