Mark,
I pretty much agree with you regarding the "done" nature of the current servlet API. In fact I think we were kind of done at 3.1 (as Jetty has still not released our 4.0 version and nobody has even asked for it!).
But I do think that there is demand and interest in new API and/or features - even a completely new API that could:
- Remove all the cruft (no JSP, JSF etc. as favoured child of servlet container)
- Remove all the old stuff (eg Enumerations)
- Support micro deployments (eg web functions)
- Perhaps reactive IO ( although I do like our IO paradigm :)
- Asynchronous/background receipt of complex content (eg form params, multipart, json, xml).
- Better support for IO interception - it is now impossible to wrap request/response objects to intercept IO because of the async behaviours (plus it was ugly way to do it anyway).
- Better demarcation between headers/features that should be handled by the container vs those that should be handled by the application.
- Sane URI mapping.
- a security model that is usable by frameworks to provide modern extensible security
- Well define session semantics so we can all agree on what a distributed session is (even if this means only native types!!)
- Use JPMS layers instead of an inverted/hacked classloader.
- Better support for HTTP/2 & HTTP/3 variations of semantics (eg connection scoped attributes?)
- Support fast start - no scanning for annotations every time a new cloud instance if started.
I can kind of see a path forward where we freeze our javax.* implementations (modulo security issues) and put all our effort into creating a new simple, modern, flexible HTTP API. Once that is agreed, we can support backwards compatibility by porting our various javax implementations to run within an adaption layer on top of the new API (which could result in some interesting outcomes - eg running a jetty servlet container ontop of a netty jakarta.* server ).
Of course without the structure of a legacy API to guide us, we may be unable to come up with an agreed new API model, but I'd much rather burn cycles trying to do that than trying to work out how to byte code modify ancient javax servlets to run on new jakarta.servlet containers.
