One argument I heard is that Servlets are much, much slower than Jakarta REST. But I'm not quite sure why a Java class that implements jakarta.servlet.Servlet should be slower in any way than a Java class with the @Path annotation.
Arjan et al,
The problem with the servlet API is that it never really knew what it was:
- A protocol API
- A web application development framework
- A framework for developing other web application framework
So this makes it a lot more complex than needs be for simple usages. Worse yet, many of the features that have been added (and then changed over the years) don't come at zero cost, even if they are being used. I blogged about this after 5.0
here, but in summary features like include and object wrapper identity have significant costs even on simple requests that don't use those features.
However, some good news is that we have taken some good steps in 6.0 to remove some of these old/wrong features. Again I blogged about the impact
here and in summary: getting rid of some "features" like Object Wrapper Identity will allow 6.0 implementations to be more efficient and to better approach the performance of none servlet based servers.
The bad news is that I don't think Servlet 6.0 is the end of the road. It is still a very fat interface with a lot of old bad practices baked in, plus it is mixed in with a lot of non-protocol stuff that really should be done in content generation frameworks rather than in a protocol layer.
So is there an appetite for a standardized low level HTTP API? There is definitely an appetite for low level HTTP APIs, but I'm not so sure that we could find a single abstraction to suit everybody (other than the jetty-12 one, which if course is perfect and all things to all people). Should it be async? Should it be blocking and based on Loom virtual threads? Should it just transport bytes and delegate content type handling to frameworks?
