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
- 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 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?