Unresolved questions about the Servlet specification

I doubt I am alone in considering the Servlet specification the most important part of Java EE. It has been some time since the first details of version 3.0, standardized as JSR 315, came out. Today I found an InfoQ article about the debate over the published Public Review, and it left me uneasy.

We have seen many times that few things are worse than a complicated specification built on the assumptions of a small group without enough grounding in real use. EJB should serve as a warning. I thought that period was behind us. Expert groups responsible for delivering specifications had begun to include people with real experience of enterprise Java. One person I trusted in this respect was Greg Wilkins, author of the Jetty servlet container.

That is why I was alarmed when someone I respect wrote the following in his response to the JSR 315 Public Review:

JSR-315 has produced a Public Review (PR) of the servlet 3.0 specification, which unfortunately is a poor document and the product of a discordant expert group (EG) working within a flawed process.

Wilkins also makes another apt point:

The API decided by JSR-315 will be with us for many years to come and will affect the evolution of java web applications and potentially the rest of our programming careers.

Exactly. Anyone who has worked with Java EE should recognize this. The Servlet API is so fundamental that taking chances with its expansion could have far-reaching consequences. Wilkins also points to other problems, such as deployment happening as a side effect or happening slowly, and an unclear order of configuration in the web application’s deployment descriptor.

His observations carry much more weight for me than code somewhere in a GlassFish development branch. With all due respect to the answers from specification lead Rajiv Mordani, I am concerned. Will we end up with a bloated specification full of vague wording? Will it actually make our lives easier? Why the rush to finish it? Is the Java EE 6 schedule driving it?

When a specification leaves questions like these, I think less is sometimes more, if only for backward compatibility. You can always extend a specification; removing something is hard. Whatever I think of JPA’s capabilities, it deserves credit for keeping its ambitions in check and drawing on practical experience with Hibernate. Developers were not made into an experiment. Servlet 3.0 should take the same path. It is too important for an experiment whose consequences may last for years.

I will close with a comment from TheServerSide:

The Java community should realize that this is one of the few ways we can really “break” Java.

Many other blunders, such as EJB, have not been very important. The usage of many packages was specialized and restricted anyway. Servlets, though, are the common starting point for Web development in Java. At present they are easy to understand and implement. If you screw up servlets and make them hard to understand or implement, you’ll lose the Java development community much faster than you might think is possible.