Cameron McKenzie: Hi, I'm Cameron McKenzie. I'm the editor
in chief over at TheServerSide.com. And I want to talk to a
little bit about the differences between Tomcat and Jetty.
Now this is actually a difficult conversation to have
because there are so many similarities between Tomcat and
Jetty. So they're both open source. They're both Java based.
They are both servlet engine servlet containers. They are
both production tested. So there are plenty of production
environments using Tomcat, using Eclipse. They both enjoy
massive community support, and they are widely adopted. So
all over the world people are using Tomcat as their
application server. They're using Jetty as their application
server, especially in micro services and small deployments,
micro base deployment, So those are some of the
similarities. So what are the differences? Well, maybe one
of the key differences is their affiliation. So Jetty is an
Eclipse project, Tomcat is an Apache project. Both open
source organizations, but I guess you can see that as one
difference the license is slightly different. Both share the
Apache 2.0 license, Jetty also is licensed under the Eclipse
license. I don't think Tomcat shares that Eclipse license
but also open source licenses. The release date is a bit
different. Jetty came out in 95, I believe where as Tomcat
was closer to the turn of the century 98, 99, and around
there. I think Jetty has gone through a number of different
incarnations. So I don't know if the original Jetty was
written in Java. Well, certainly, IT Jetty came out in 95
and Java was released in 96. So unless they had some sort of
time traveling spacecraft, I don't think Jetty could have
been ready originally in Java. But they've moved closer and
closer and closer to a full Java implementation as has
Tomcat.
So, the release date is different, market shares also a big
one too. Tomcat in surveys, I see Tomcat having any where as
low as one third of the market and as high as 60% of the
market. And so I'm sure that the actual numbers somewhere in
between there. But Tomcat is the most widely used Java
application server in the market. Jetty usually see around
the 10% number. So that's kind of the comparison. There are
certainly more in production implementations of Tomcat than
Jetty, but that does, that's not a reason neither here nor
there to use one or the other. Performance Jetty has always
taken an eye towards performance specification support.
Tomcat, is you know, often the reference implementation for
the servlet and JSON specification. And originally they
were, I'm not sure if they still are. But even then, when a
new specification comes out, Tomcat works very, very hard to
implement that specification. Jetty prioritizes important
features that their users want over chasing the latest
specification. And so the last thing there is perception.
And I think the perception is certainly that Jetty is the
performance server to go with if you need fast startup
times. You need massive performance go with Jetty. And I say
perception because it's always tough to figure out, you
know, true performance metrics. And it's always difficult to
to look at a performance metrics that's been published, and
then compare that to how you're going to be using your
server. And of course, in a lot of benchmarks at Jetty tends
to do well and it tends to do better than Tomcat, but at the
same time, is that because the the people who were working
on the application were really performance minded and they
just happened to use Jetty because performance-minded people
like Jetty? Or is it because Jedi is so much faster? You
know, I'll let that all allow the performance people to
answer that question. But certainly the perception is that
Jetty is faster at runtime, has less of a footprint, and can
start up faster than Tomcat. But neither of them are sloths,
they're also, they're both very, very good.
Unknown: I mentioned specification support. I found this
quote over on the Webtide, Webtide site, in a post about the
Jakarta naming. And I thought this was interesting because,
you know, I say, hey, Tom Cat is really, really fast to
support the specifications. So, you know, people would
think, Okay, well obviously Tomcat is better because they're
supporting the latest spec. So I saw this quote on Webtide,
it was about supporting Servlet 4.0 and Servlet 4.0 didn't
have, you know, a huge number of feature enhancements over
3.0. And so Jetty hasn't been too fast to support Servlet
4.0. And here's the justification said, despite being two
years late, was Servlet 4.0, "we have not received a single
user request asking for Servlet, for features, or release
date." On the other hand, there's been interest from our
users and more significant changes, some of which we have
already started supporting in Jetty specific APIs, including
jpm s integration, minimal startup times and micro
deployments of web functions. So I think that's a pretty
interesting attitude. Difference between the two servers,
you know, one is, hey, there's a spec, we need to implement
it. The other one is luck. There's a spec will implement it
when our users start demanding that but our users have got a
bunch of other demands first, and and we're going to go
after those before we actually chase the spec.
So I think that's that's pretty a pretty interesting
comparison. So, but obviously the question is, which one do
you use? Well, they're both solid choices. I've been a user
of Spring for a long time. And Spring ,when you do a
deployment, I think the original Spring TC server was just
an enhanced Tomcat server. Even now, when you're doing
Spring boot testing and deployment, the default server is
Tomcat that Spring uses. Although just a couple of Maven
changes and you can use Jetty. But you know, right there,
you know, you've got, you know, pretty major player in the
Java server side, microservices, environment, you know,
using Tomcat as their default. So I do a lot of Spring
development and and kind of that pushes me in the Tomcat
direction. You know, having said that, you look at Jenkins,
they package Jetty with their standalone version of their
continuous integration tool. And the CEO of Cloudbees, who,
and they do a lot of the maintenance on Jenkins. He is the
former CTO of JBoss. And so and I think JBoss embeds Tomcat
inside of it. So if he's actually been part of the decision
to use Jetty, I mean, that speaks to me really loud about
Jetty. You know, so for me, I've got a kind of history
Tomcat. So I choose Tomcat. But the more I read about Jetty,
and the more I work with Jetty, the more I realized that,
you know, Jetty really does seem to have some major
benefits, especially when it comes to modularity and
performance. And so, you know, I start to think, you know,
hey, maybe if I was doing a lot of microservices
development, or I was in situations where performance it
really is a priority, you know, I think I'd start leaning
towards Jetty and I think I would make that Jetty decision.
So, you know, it's a tough decision, you know, which one
performs best for your specific workload.
Don't just look at benchmarks, you know, do your own
benchmarks. How, where's your server going to be used? A
lot, a lot of the people I talked to a lot of people, I work
with our enterprise customers and enterprise customers, you
know, a lot of times, you know, maybe insurance companies,
governments, you know, they don't have the same performance
that somebody on the trading floor of the NASDAQ stock
exchange needs. So, you know, know your workload, know your
demand, know how it's being used, and then benchmark it
appropriately. Take a look at what kind of support you have
on your team for Jetty or Tomcat, you know, what are your
users most familiar with? And again, I hate thinking that
something is popular remains popular just because it is
popular. You know, don't choose something just because it's
popular. Choose something because it fits with your needs.
But you know, how much support you have in your
organization? That's that's a pragmatic thing you have to
look at. Also, what other products you have that integrate
with it, and do they support Tomcat or Jetty, and also you
don't maybe philosophically, is your organization in line
with what we see from the goals of the Jetty or Tomcat
community? Right? So Jetty seems to be really reactive,
"hey, this is what our users want. This is what we're going
to give them. And, you know, we're not going to chase the
spec as the other." On the other hand, Tomcat, "Hey, there's
a spec out there, we want to be one of the first, if not the
first, to implement it, and provide a ready server instance
for it." So so you know, philosophically those are two
pretty big contrast between the two of them. But either way,
you can't go wrong. I wrote an article on this. And you
know, I kind of said, you know, regardless of which side you
taken that Tomcat versus Jetty debate, you can't make a bad
decision. Both are used widely used in production
environments, they have proven themselves. It's part of an
endless bounty of open source riches. We have in the server
side and Java world and that really is the truth. So choose
between the two, choose wisely, but quite frankly, I don't
think you can go wrong with either. My name is Cameron
McKenzie, go follow me on twitter @cameronmcnz, take a look
at some of the stuff we're doing over on TheServerSide, and
finally, thanks for watching.