Servlets 3.0

I’m just fresh out of a session at JavaOne where Sun have revealed their road map for the servlet 3.0 specification. My initial reaction is that it contains both some good and bad items as well as quite a few concerns in between.
The 10 words or less version is: Annotations, JSF, Ajax, Comet, REST, scripts, security and Misc.

Java Community Process

My first concern with the road map is that I, as a member of the JCP servlet expert group had to go to a JavaOne session to see it for the first time. I hope that this does not signal a return to the bad old days where the JCP was used only as a post process rubber stamp for Sun’s internal design process. The talk did mention consultation with the expert group, but I would have been less concerned if we have been involved in setting the agenda as well as helping find a solution for it

Annotations

I’m not a huge fan of annotations, but given that they are already in 2.5 the additional annotations shown all looked reasonable. The aim is to make web.xml either redundant or at least only used for deployment overrides of reasonable defaults.

Java Server Faces

There was a lot about improved integration with JSF. This may be good or bad, but I don’t really care either way. I continue to not understand why the servlet specification should be closely tied any one web framework. The servlet spec should be web framework neutral and having a “favored son” will just lead to more special cases – like the need for all webapps to scanned for JSP and JSF descriptors even if they do not use JSP or JSF!

Ajax Comet

The good news is that support for Ajax comet (Ajax Push) is on the agenda. The bad news is that the talk appeared to describe the only use case for asynchronous servets to be Comet Ajax, and then only the forever response flavor of that. As I have described in my blog, Ajax Comet is only one of many use cases for asynchronous servlets. Any servlet that might block for a JDBC connection pool, a remote webservice or any other slow resource could benefit from threadless waiting support. So I hope the agenda revealed was only a subset of the use-cases to be addressed and not the limit of the vision.

REST

The integration of REST support will be welcomed. Well designed REST support will allow developers to focus on content rather than HTTP protocol. The annotations shown looked like a good step in the right direction, with my only concern being the use of streams to define content could restrict servers from efficient non-blocking handling of content. Hopefully other ways to provide content can be included.

Scripts

Exciting development to allow alternate languages other than java to run on the JVM and produce content efficiently through servlets. One size does not fit all and one language does not suit all. Looking forward to this bit.

Security and Misc

Web security has always been lumped in with Misc in the servlet spec and thus is half baked. In the road map it got its own heading as it deserves and hopefully this blog will be the last time you see security as Misc.
Most of the other sore points in the servlet spec (eg welcome files) were listed as needing attention in 3.0

Summary

It is important that we keep servlet spec relevant to the way developers produce content. If servlets do not grow to support most of the issues mentioned above, then developers will continue to find ways to bypass standard servlets. Servlets are a key foundation to the whole JEE stack and if they are bypassed, so much of the work done to achieve interoperability and standards will be lost as different foundations are used by different web innovations.
So while progress on a 3.0 servlet spec is well overdue, I welcome Sun’s statement of intent and look forward to the months ahead and hope that some good solutions may quickly be agreed and specified.