Why there is no servlets in Play
Creating a Java web framework without relying on the Servlet API can seem very strange. Most people ask why this uncommon choice? Some love it, others hate it. To be honest the very first versions of the play framework were using servlets and were running in a servlet container. But there are many good reasons why we decided to remove this requirement. I’ll try to explain.
There are two important points (among many others) in play framework: it is based on a completely stateless architecture model, and it auto-magically reloads your code changes. In fact these two points are intimately imbricated.
Making an application stateless is the only way to allow code hotswapping. Have you ever wondered why it just works with PHP while it’s not possible with JEE (I mean, not redeploying the war in the background, but really hotswapping the application code)? It’s just because PHP is totally stateless; between two successive requests, it will restart a fresh PHP process (OK there are some optimizations now using FastCGI but it doesn’t change the underlying model). If your application is not stateless, there is no way to rebuild the in-memory state after the code swap. It could work on some cases, but it will likely fail after any important change.
Allowing code hot swapping is not the only reason why we decided to make of play a stateless web framework. It’s not really the point of this post, but basically, it’s just because the WEB itself uses a stateless architecture. And there are very good reasons for that.
Now, you can always use the servlet API and build a stateless application with it. However you’ll have to refrain from using some features like the HttpSession or the servlet forward mechanism. That’s what we did on the first versions of play framework.
But sincerely, people don’t want access to the servlet API because they love it. Everyone agree on the fact that it is the worse HTTP API ever conceived. No, they want to access the servlet API to be able to reuse existing servlet based components like servlet filters, etc.
The problem with these components is that they are usually poorly designed. They store objects in the session, mess with your HTTP requests and responses objects in your back. So there is a great chance that installing a component like this will break the initial stateless contract of play and lead to a lot of class reloading and class cast problems. It is also because your application has to live in a play custom classloader in order to be reloaded. And to be used the servlet components need to live in the servlet container classloader. Do you need any cooperation between these components? Of course you do. And it will be a nightmare.
In fact there are two kinds of servlet based components. I was faced to this problem when I was searching for a captcha library for play. Some use two well separated layers, one with the captcha generation logic, and the other one for the servlet API integration. The other kind is a mess of imbricated code that you can’t use without using the servlet API yourself. For the first kind you can always use them with play by using only the interesting part. For the other kind, chances are high that it would have broken your application if you were able to install them in play.
Finally there is a last reason why we don’t use the servlet API anymore. A servlet container uses an old fashioned “one thread per request” model. It can be OK for some applications. But these days with all these Ajax and long polling calls, it is not enough.
I think that the fundamental problem is that using the servlet API is the only way you can plug with the HTTP layer of a JEE server. Perhaps the java ecosystem needs something like Rack. I mean, a real low level and portable API to deal with HTTP. Not an half assed HTTP API built on some flawed architectural principles.