In a recent article, Jason Hunter runs through the new features present in a maintenance release of the Servlet specification. The decision to bump up the version number from 2.4 to 2.5 was based on the significant changes in the specification. In this release, there are four clarifications, two alterations to other documents, and the addition of six new major changes in the specification.

Many of the most significant changes make use of the new language features found in the JDK 1.5. As a result of the decision to use annotations, that version of Java has now been specified as the minimum required runtime environment. In the list of clarifications we have:

• calls to getReader() that have not been preceeded with a call to setCharacterEncoding() will acts as a no-op
• calling setHeader() with the arguments "Content-Length" and "0" will close the reader to further alterations. All subsequent calls to setHeader calls will be ignored
• calls to HttpServletRequest.isRequestedSessionIdValid() will now return false if the client did not specify a session ID

The new features that can be found in this specifications include:

• Clarification on Session scope for when pages contain more then one session context
• the ability to apply a single filter to many requests and many filters to a single request
• the ability to create multiple mappings to the same Servlet
• Allow the use of alternative HTTP methods with authorization constraints
• Support the use of annotations to inject resources into a servlet
• Removal of the restriction on not being able to call setStatus() in error handling

In the closing paragraphs of the article, Jason adds a "wish list" of features that still to be added to the specification. Included in this list is support for NIO to which he comments that "it's possible that NIO Channels would be a more efficient way for servlets to communicate with clients."

In the March of 2004, IBM-DW published an installment of Eye on Performance that focused on how a Brazilian online gaming company (MegaJogos) was unable to scale to meet user demands until they started switched their server to use the NIO package. Given the problem domain, one may consider this to be an edge case, but one must also consider the growing popularity of AJAX. AJAX-enabled web clients will most likely utilize many more connections than traditional web clients. It is for this reason alone that Jetty has moved to encorporate NIO into their latest 6.0 release. With NIO, Jetty 6.0 is much more capable then it's predecessors to handle the stress that AJAX can place on web servers.

In light of this, one has to question why this JSR decided to focus on adding annotations (a much newer feature) for yet another version of init() (@PostConstruct), destroy() (@PreDestroy)and resource injections. In the BileBlog, Hani Suleiman lists functionality that he would have rather seen be implemented. What makes this blog particularly interesting is that Hani is a member of the JCP Executive Committee (EC). The EC according to JCP 2.0 procedures for a specification in maintenance is to "review all proposed changes to the specification and indicate which ones can be carried out immediately and which will require the specification to be revised by an expert group." From his blog it is clear that Hani has problems with the specification as it has been released. But if he is part of the group that is responsible for reviewing these changes the question is, why was he was not able to effect the changes he felt were necessary?

The JCP as an organization has been beneficial to Java in that it has provided a forum for all to express their views and contribute to various aspects of Java. The community has extracted many benefits from this process: for example, the unexpected work on concurrency by Doug Lea that is now an integral part of the JDK. That said, the process, as is the case with any process, is less than perfect and given this it can be expected that there will be dissenting voices on any decision that is made. The authors of this specification clearly have not meet Mr. Suleiman's expectations -- or the expectations of others such as Brian McCallister and Howard Lewis Ship.

The question is, have the specification maintainers met yours?

calls to getReader() that have not been preceeded with a call to setCharacterEncoding() will acts as a no-op

I might be missing something, but isn't this going to break a whole load of existing code?

I believe the summary is incorrect; My understanding was that, in the 2.5 release, if a call is made to getReader() followed by a call to setCharacterEncoding(), the getCharacterEncoding() is treated as a no-op, not the initial call to getReader().

rob.

As Hani pointed out in his bile, the features/changes listed are definitely not worth the version increment... how long again did it take for them to get from 2.4 to 2.5 with only these set of features?

As Hani pointed out in his bile, the features/changes listed are definitely not worth the version increment... how long again did it take for them to get from 2.4 to 2.5 with only these set of features?

The biggest missing feature that was mentioned but left out is actually built-in multi-part MIME handling.

NIO is well and good, but the Tomcat folk have not managed to get it to work really well across platforms. They have, however, managed to get good results with APR. The Tomcat folk are bright guys so I see this as a damning statement of either the current usability, the current cross-platform quality, or both of the Java NIO.

As servlet lead I get many requests for changes and I very much like to see the servlet specification evolve. But when you have many technologies built on what your are doing changes can cause problems. With Java EE 5 we decided to focus our efforts and resources on making sure the other web tier technologies play well together.


The servlet API is showing its age is not broken. Could the security model be better? Yes. Should we support multi-part mime requests (aka file upload)? Yes. Can you implement the APIs on top of Java NIO? You sure can, though it would be better to expose some new APIs. For a list of some of the suggestions I've gotten see my blog entry Got Servlets.


I would like to see the changes in a future specification though you need to ask yourself. At what point do you keep adding layers to what your are doing. In order to ensure compatibility we just can't rip and replace portions of the specification. I'm sure there would be many more complaints.


Maybe the better question to ask would be: Is it time to rethink servlets all together in light of AJAX, NIO, Java 5, and everything we've learned in the past years?

Don't sweat it, Greg. All the interesting stuff is happening above the Servlet API nowadays anyway. Is it perfect? No. Is it worth spending more time on? Probably not. The people who think it is should volunteer their own time (Hani ;)).

Is it time to rethink servlets all together in light of AJAX, NIO, Java 5, and everything we've learned in the past years?

Most definitely. Servlet 3.0.

As servlet lead I get many requests for changes and I very much like to see the servlet specification evolve. But when you have many technologies built on what your are doing changes can cause problems. With Java EE 5 we decided to focus our efforts and resources on making sure the other web tier technologies play well together. The servlet API is showing its age is not broken. Could the security model be better? Yes. Should we support multi-part mime requests (aka file upload)? Yes. Can you implement the APIs on top of Java NIO? You sure can, though it would be better to expose some new APIs. For a list of some of the suggestions I've gotten see my blog entry Got Servlets.I would like to see the changes in a future specification though you need to ask yourself. At what point do you keep adding layers to what your are doing. In order to ensure compatibility we just can't rip and replace portions of the specification. I'm sure there would be many more complaints. Maybe the better question to ask would be: Is it time to rethink servlets all together in light of AJAX, NIO, Java 5, and everything we've learned in the past years?

Time to rethink. I don't see it like that. As an AJAX, NIO and especially JSE 5 fan I still don't see a need for a major rethink of the Servlet API. Lets tackle those
in detail.

Firstly, while AJAX would benefit from a direct connection and less of the request-response over HTTP we have these days, the reality is every shop only has 80/443 open and the protocol is HTTP. Perhaps this will change in the next decade and we'll see port 8081 open for AJAX business.

Secondly, the servlet API is stream-based. It has been shown how this can easily be fitted into an NIO scenario; by adapting NIO to ServletStream (less performant) or small
addition to the Servlet API to make it event/packet driven.

Java 5. Are you thinking annotations for the Servlet API?


Cheers,

Gary
____________________________________________________________

I have to admit that I am a little disappointed in the list of changes for 2.5. Mostly I agree with what I've read in Hani's and HLS's blogs.

I'm glad that the expert group took the time to clean up ambiguities and inconsistencies, but it seems to me like the whole annotation addition to the spec was really a waste of time. Frankly I don't think many people (other than framework authors) write servlets on anything like a regular basis. And even for those that do write servlets, I think these annotations are of minimal value.

Mostly I wish the EG had taken the time to add some more useful things to the spec. HLS was right that full regex support for URL patterns would be fantastic (not to mention easy to implement and maintain backwards compatibility). As Hani pointed out, in-container multi-part mime would rock, though that's undoubtedly a bit more of an addition.

But my favorite missing feature of all time is the lack of ability to programmatically log the user in. It seems like every app I build we end up going with a different security solution because the user experience imposed by the servlet spec's logon system is unacceptable.

-Tim Fennell
Stripes: Because web development should just be easier.