On June 12, 2015, the Jetty Project released version 9.3 of their flagship open source embedded application server, that day being the 20th anniversary of the project's beginning. Features of the release include HTTP/2 server (and client) support, Java 8 as a minimum, more Java NIO integration and an overhauled scheduler. They also removed SPDY networking support and fixed over 400 bugs since Jetty 9.2.x.
Greg Wilkins, lead developer of Jetty, wrote a blog post about HTTP/2 in Jetty. In it, he describes how to easily enable HTTP/2 support by specifying it in the Jetty startup command.
$ java -jar $JETTY_HOME/start.jar --add-to-startd=http2,http2c
This doesn't create or enable new connectors/ports, it just adds the HTTP/2 protocol to the existing connectors on ports 8080 and 8443. The latest versions of most modern browsers support HTTP/2. To find out if your browser supports HTTP/2, see http://caniuse.com/#feat=http2.
To learn more about 20 years of Jetty, InfoQ sat down with Greg Wilkins.
InfoQ: Congratulations Greg, I'll bet you never expected to be celebrating 20 years of Jetty!
Indeed - I started it as simply a module within an issue tracking webapp I developed and never thought there would be interest in it at the start. But there was and HTTP server became the main focus of my efforts (should have stuck with the issue tracker and become Atlassian. :)
For the last 10 to 15 years I've been expecting web servers to become so commodity that it does not matter which one you use. But things never stay the same: the JVM changes; the standards change; the way we optimize servers changes; the way we develop webapps changes. So there have always been aspects of Jetty that need to change and with change comes differentiation from the other containers.
InfoQ: It must be quite a challenge keeping up with all of the new standards and requirements like WebSockets and HTTP/2. Can you give us some insight into the process you must follow for discovering and then for implementing these requirements?
Being part of the expert groups within the JCP and IETF is how we stay current on the standards development and we like to think that we sometimes lead as well as follow the standards. However, I think that our best innovations have come from real use-cases from real users and being part of a wide and diverse open source community is key to how we find those use-cases: Asynchronous servlets originated as a feature request from ActiveMQ; websockets came to our attention because of cometd in dojo; and we are currently investigating reactive stream APIs because of interest from users.
InfoQ: How has the increase in microservice deployments impacted Jetty adoption?
Jetty certainly gets used for microservices, but I would hope that it has driven uptake of Jetty (but always hard to tell in true open source projects). However, so far, microservices have not yet driven any significant changes in Jetty and I'm hoping that is because we've always been designed for simple embedded usage and there is nothing new that is needed.
InfoQ: There is quite a bit of competition in the application server market, especially Tomcat in the open source arena. How does Jetty distinguish itself so successfully?
We don't feel all that competitive with the application server market because we don't really try to compete in the full EE space or even in the partial web profile space. Sure Jetty can be used for EE deployment, but we believe in component oriented development and don't see why your HTTP protocol provider should be responsible for persisting your business beans, managing transaction or generating your content. There are plenty of other components for such things and we focus on what we are good at: providing scalable protocol implementations for HTTP, HTTP2, Websocket, FCGI etc. and let our users pick other components for the rest of their application. We also make sure that we play well with other projects so that integrating CDI, JSF, JMS, ETC. with Jetty is straightforward and efficient.
If anything, we feel more competitive with the lightweight HTTP servers that are focused on scalable asynchronous micro services. There is some innovation in this space and we are keen to ensure that we will support the semantics that they are aimed at whilst still providing the Servlet API. So we differentiate ourselves by providing similar scalable flexible asynchronous HTTP but with full access to the Servlet API if needed.
This flexible approach is certainly having traction in the market and you look at our biggest deployments in places like Google, Yahoo, Facebook, Salesforce, LinkedIn, they are all significantly different to each other and none of them are remotely like a stock EE usage.
InfoQ: When do you plan on releasing a version that's compatible with Servlet 4.0?
Jetty 10 will be Servlet 4.0. However we are not yet sure exactly what will be in 4.0 and the process has been a bit quiet of late. So no idea of a due date on that or what the compelling features will be.
InfoQ: What's on the horizon for Jetty?
Nothing definite yet. We have some ideas: Reactive streams; improved CDI integration; Websocket over HTTP2; Quic. We've begun experimenting with some of these, but need some real user demand for specific use-cases before we can solidify these rough ideas into a plan.
Jetty support is available through Webtide. In fact, their Professional Services site is used as a testbed for HTTP/2.