The Java servlet containers available today seem to focus on performance and scalability at the expense of speed of development and agility.

There is a significant business opportunity for some company to produce a Java web server optimized for development. The usage patterns and requirements in each environment are different enough that it makes sense to produce different product optimized for each scenario.

To take the example I know best, Tomcat is quite slow to start up with a large application, is painfully slow at JSP compilation, and does not allow changes to models, controllers, and configuration to be reliably applied without restarting the web server. (After a few restarts you typically get a permgen memory error.) And of course I have to manually rebuild my classes after making a change rather than having the server notice automatically.

If Java feels significantly less agile than, say, Ruby on Rails, at least part of the blame must rest on the application servers that we use to run it, and the fact that they penalize every little change with such expensive restart times.

There are of course other factors (between strictly typed languages and dynamic language, and between different frameworks, for example) that play a role in agility, but we ought to be able to at least compare the languages and frameworks on their merits without having the additional albatross of a developer-hostile web server to deal with.

The beauty of a standard like J2EE is that it allows multiple implementations optimized for different purposes– development vs. production, for instance. My dream development server would start up in a second or two, would never need to be restarted when I made changes, and would intelligently rebuild whenever source files change. (Optimizing for developer performance is just one example of where we can much better than the current state of art– ease of debugging is another good example.)