Servlet 3.0 Public Review Sparks a Debate

JSR-315 has produced a Public Review (PR) of the Servlet 3.0 specification, accompanied by a reference implementation in the GlassFish trunk. This release has resulted in a debate around the choices that the Expert Group (EG) has taken for the next generation Servlet APIs and the whole of the Java EE 6 platform.

The Servlet API has always been a bit rough around the edges and since the Early Draft, the JSR 315 EG has been working on refining and improving the specification in areas like Ease of Development (EoD), pluggability and asynchronous support, as Rajiv Mordani, who is one of the Spec Leads, describes:

• Ease of Development (Eod): In the early draft we added the annotations that allowed you to essentially write a Servlet as a POJO. However after some discussions in the expert group and feedback from some folks in the community, we decided to actually remove the method level annotations like @GET, @POST etc and keep the doGet, doPost method contracts and require extending an HttpServlet. However the top level annotations which are renamed for better usage in applications still exist. The @WebServlet annotation is used to declare a servlet, @ServletFilter to declare a filter and @WebServletContextListener to define ServletContextListeners. In addition to these annotations, other annotations like @Resource, which have been supported in web applications since Servlet 2.5 will continue to work as before.
• Pluggability: Web frameworks built on top of servlets are very popular for developers and there are a lot of them that address various different problems. In order to better support frameworks for developers writing webapps we are adding ways in the servlet 3.0 specification to make it easier to use and configure frameworks of their choice.
• Asynchronous processing: This is the biggest change that we have made in the servlet 3.0 specification. In the early draft we had suspend and resume and certain semantics that were defined. However after the early draft the expert group had a lot of discussions on solving various use cases for asynchronous processing and the changes that are made to the specification in this area now also address the various use cases.

Roy Van Rijn had expressed his concerns about some features that were presented in this Early Draft:

My preference would still be not using annotations at all for GET/POST methods, but I've read the Java EE 6 specification is promoting the use of annotations like this and the JSR-315 writers have 'no choice' (bad excuse). The comments I made in this article have been send to the JSR-group, but I haven't got a response yet.

Also I've been unable to reach members for a reaction and/or explanation and/or clarification. Recently the Java EE 6 specification went on public review, and it contains references to this Servlet 3.0 specification, so it will become part of Java EE 6. This must mean they are working actively, maybe even franticly, to finish it on time. But I plead them to take the time to reconsider their choices about the annotations.

With the release of the Public Review (PR), Greg Wilkins from Webtide, has been arguing that the spec is “poor document and the product of a discordant expert group (EG) working within a flawed process”. His main arguments against the PR are:

• It represents a thought experiment in API design unhindered by the complexities of implementation, trial usage or community feedback.
• Requests for test implementations have been denied.
• There is no open or considered mechanism to collect requirements from the community and precious little community consultation.
• Some unsubstantiated requirements (eg. wrapped asynchronous requests) have been included at a late stage without any use-cases or user demand.
• It has been badly written, as most other JCP documents.
• Some of the new features raise security concerns and may cause slower deployment.
• The proposal for asynchronous servlets has diverted from the course it had in the Early Draft. The original approach was the result of Jetty Continuations and had been available as a trial implementation in the pre-releases of Jetty-7 since March 2008 which has been tested by many frameworks and applications, including Cometd, DWR, JSF and BlazeDS.

Greg concludes that:

I believe significant errors are being made in the current PR and that the flaws in the process have been enough to prevent the application of due diligence sufficiently for these flaws to become self evident. While I have received support in the EG with the debate on these issues, I have been unable to convince the spec lead of their validity and I have probably not helped the cause by some over-vigorous participation in the debate.

Rajiv’s answer to Greg points out that:

• An implementation is available in GlassFish.
• He never saw a request of feedback from Greg.
• The new features can be switched off if they are not desirable.
• There is no solid argument about making deployments slower
• The way the proposal for asynchronous servlets has been growing is perceived better by the community and he quotes emails to the EG.

Rajiv also refers to a blog post that Bill Burke from RedHat had made, where he criticized the implementation of async servlets in Jetty 6 continuations.

Afterwards, Greg Wilkins announced that he has been working on an implementation of the Servlet 3.0 asynchronous servlets with some of the fixes/extensions he had suggested in his blog and from some continuing discussion within the EG. These are:

• A new ASYNC DispatcherType for redispatched asynchronous requests
• The isAsyncStarted() method is false when a request is redispatched.
• An IllegalStateException is thrown is startAsync() or startAsync(request.response) are called if getReader() or getOutputStream() have been called.  This restricts asynchronous handler to the simpler cases.
• If asynchronous mode was started with startAsync(request,response), then it is an IllegalStateException to use any of the forward(...) methods on AsyncContext. This avoids the complication of redispatching wrappers, but allows wrappers to be used by asynchronous handlers.
• The forward(path) and forward(context,path) methods have not been implemented.

The code is available at a branch of Jetty and branch of the servlet-api.

Greg wraps up on the async servlet issue:

While more testing is needed, this implementation demonstrates that significant asynchronous behaviour can be implemented without the complexities of redispatching wrapped requests or the forward(path) methods.  I believe it represents a reasonable compromise for 3.0.  If additional features are required, surely they can be added in 3.1 after we have gained experience with a simpler subset from 3.0?

You can find more information on the Servlets, GlassFish, Jetty, Comet and Java EE right here on InfoQ.