Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] What do we exactly dislike in Servlet?

On Wed, 13 Jul 2022 at 05:57, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
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?

At the very least, I'd like Servlet 7 to look at splitting the servlet spec into the pure API concerns and the application framework concerns (eg war packaging, annotations, descriptors etc.).   Perhaps the core API will not be to everybody's taste or meet every need, but it might be simpler and fast enough such that it's standard nature provides something good enough for many non servlet usages.



Back to the top