Sitting On The Dock Of The Bay: An Interview With Jetty's Greg Wilkins

December 02, 2006

This is an interview I did via email with Greg Wilkins, the man behind the Jetty servlet container/web server. I have been using Jetty since its early days in any project where I had a choice, and it is currently serving up this blog. This is the second interview on the folks behind the technologies I use every day.

A brief biography (ie your education, where you live, work, whatever you want to share)

I was born in Australia and studied Computer Science at Sydney University and graduated in 1986. My early career was mostly communications for the military and telecoms using pascal and C . I discovered Java in 1995. In 1997 I moved to the UK and worked in London City until 2003, at which time I relocated to a small Italian hill village - wired with broadband. And I'm still here (Colletta)

What do you do for a living?

I've been self employed consultant since 95. Over the last 10 years more and more of my time has been directly involved with Jetty and associated open source project - and occasionally I get paid for that! Initially I worked through my own company Mort Bay consulting with my partner Jan Bartel. This last year, we have relaunched with a partner and are now called This is an effort to upscale the support and development services available for Jetty and offer them at a scale and quality appropriate for larger clientèle.

How did you start working on Jetty? What was the motivation?

In 1995 I was consulting to an C /smalltalk consultancy who wanted to recruit me as a principal engineer. In order to do so I needed a business sector and I suggested the very new Java. The CEO responded saying that there was no money in Java and never would be - it was just a toy. So I quit and to wrote a web based issue tracker in java as an entry in the Sun Java programming contest in December 1995. My entry won, but nobody had liked my issue tracker, but the judges had liked the HTTP engine I had written as a by-product. This over the next 2 years became Jetty and the International Petroleum Exchange in London were my first paying clients that put Jetty into production in 1997.

How have you stayed focused on Jetty for so long?

It has been a while. But I have not been focused on Jetty the whole 10 years. There have been periods with very little jetty development and/or interest. But then there is always something new cropping up to renew interest.

The servlet spec helps... the dang thing keeps changing! New JVMs also bring interest. And now the move towards Ajax is changing a lot of the design assumption used to build the web infrastructure.

I've worked with people who said Java was too slow to serve static content and required a webserver "written in a real language, like C" be in front. How do you respond to that?

Java is a good server side tool because it allows the developer to ignore a lot of the boiler-plate needed to keep a server running and focus on the job at hand. It is a simple language without too many bells and whistles and has a capable and moderately standard set of libraries of reusable code. Thus it is a great language for building server side business logic.

If the performance of that business logic is going to be dominated by the time need to parse "GET /myapp HTTP/1.1" and a few headers, then I'd have to conclude that your business logic is pretty simple and my well be able to be well developed in C.

So for most non-trivial webapplications, it is the backend logic that dominates the processing time (or at least latency). Putting some C code up front may parse HTTP headers quicker but at the cost of extra complexity, extra communications and double dispatching.

Now there are some resources (Eg static) that are better served by native HTTP and a well designed application deployment will allow for to be served by dedicated native servers. But there is no good reason that these servers have to be in the network path between client and business logic. In fact, most large deployments are farming out their static content to third parties with global infrastructure for serving it.

Finally, java is very good at multi threaded protocols. The long polling technique used by comet and Ajax push applications required asynchronous handling of long held requests. This is moderately easy to implement in Java and all the main java web servers either have a solution or are working on one. However even the latest version of apache with it's reworked threading models cannot asynchronously handle long held requests. I believe this is a good indication that it is simpler harder to refactor and work with threads in C.

Finally Finally, from a security point of view nobody can seriously say they prefer C rather than Java to terminate outside connections?!?!

Where/how does Jetty fit in, between for pay systems like WAS, BEA, and opensource containers like Tomcat? Is there room for so many options? Why would someone want to pick Jetty over the others?

Well firstly diversity and choice are good things, as it a bit of healthy competition.

With regards for the for-pay systems, I firmly believe that dealing with HTTP should be commodity infrastructure and that as such should be open and free.

Because Jetty is a good software component, it is often embedded seamlessly in other projects, most developers are probably using Jetty regularly and do not realize it. It can easily be hidden and is flexible enough that configuration mantras do not need to propagate to the user.

Two years ago Servlet containers, were pretty much commodity and technically it probably didn't really much matter which one you used. It was more a matter about marketing, support relationships and developer relationships.

However, web-2.0 has changed all that. There are significant changes need in the web infrastructure in order to deploy scalable Comet / Ajax push applications. All of a sudden web servers are not commodity again. And this is where Jetty's strengths are coming to the fore. Our innovative thinking allowed us to design a good solution (Continuations) and our good code base has allowed us to refactor and redesign to integrate it. Our good relationships with other developers/projects has allowed us to integrate this feature into many other projects such as maven, activemq, DWR, DOJO, jboss, geronimo, glassfish.

What is the future for Jetty?

I want Jetty to continue being a developer friendly project and to be the web server of choice for embedding in other projects. There are also many exciting opportunities to explore the possibilities of created by the asynchronous handling paradigm (such as asynchronous proxies and web services) and I'm making an effort to find time to explore those.

But I'd also like to see Jetty step up a rung or two on the corporate awareness ladder. With web-2.0, web attacks, DOS, etc. there is a constant challenge being made to the web infrastructure that sustains many businesses.

While I firmly believe that this infrastructure should be open, that does not mean it should be unsupported. So many business have unsupported open source infrastructure deployed. Support for OS infrastructure is a win-win as it insures vital business infrastructure and contributes back to the community that developed that infrastructure.

It is important to select the right infrastructure and the right partners to support that infrastructure. I'd like for Jetty and Webtide services to become more firmly established in that space.

Jetty Home