I have Servlets
In Got Servlets?, Greg is asking what we'd like to see in the next major revision of the Java Servlets specification. In no particular order, here are my initial thoughts.
- Programmatic access to the security realm : There are more and more sites out there that offer users a way to sign up for their services and this is fairly tricky to do with the standard, declarative J2EE security model. If you know that you're using a particular platform (e.g. Tomcat), then you can write some code that takes advantage of the underlying way in which the security credentials are stored, and edit them appropriately. But what about when you're targeting more than a single application server platform? What about when your team is developing on Tomcat and deploying to WebLogic? In this situation, being able to access an abstraction of the underlying realm implementation would be very useful. Self registration then becomes much easier - create a principal, assign some roles and write it back to the underlying realm in a platform independent way. Yes, you can do this with external security frameworks, but it would be nice to have this as a part of the standard.
- Programmatic access to the security constraints : Following on from the point above, programmatic access to the security constraints of the current web application would also be really useful. Self registration on it's own lets you build applications where the content presented to the user varies based upon who that user is. However, what you can't really do is change the security constraints of the web application on the fly. For example, imagine you're a blog hosting provider. You might want to let users self register for a public blog. On the other hand, you might want to let them register for a private blog, secured by the declarative security constraints in the web.xml file. Given the choice of using filters or security constraints in the web.xml file to permit or disallow access, I'd rather use the declarative approach because it's tried and tested code, reducing the risk that my site will be breached. This is one of the major benefits of using declarative security - the container does this work for you. Again, stopping people reinventing the wheel each time the security system doesn't work for them would be nice.
- Specification ambiguities : Inconsistency through ambiguity is a major headache for many developers, although I'd say that it's an even bigger headache for people wanting to build J2EE applications that really can run anywhere. Take Inconsistency between Servlet specification implementations as an example. Some containers provide you information about whether a user is logged in and some don't. Things like this really do need to be addressed. At the heart of this problem are ambiguities in the specification, but I'd say that the test cases around specification compliance need to be greatly improved. After all, what's the point of having a bunch of "J2EE compatible" application servers if they are inconsistent in how they implement the specs. Greatly reduces the benefit of the certification, don't you think?
- Regex URL patterns : The current wildcard scheme for specifying "url-pattern"s is far too limiting. Regex support would be nice, particularly now since newer versions of the J2EE spec mandate the use of versions of J2SE that contain regex support.
On a more general note, admittedly I've not used Java 5 annotations much, but I'm one of these people that is a little bit skeptical of them. They do have their uses, but I am a little concerned about them being overused, for example, to configure components through the code. Mike Spille has a great blog entry named Action Hippo Rangers! where he talks about the ping pong nature of software development. One of the examples he cites is the adoption of annotations versus XML configuration. The point is, just because XML configuration is seen as complex and verbose, this doesn't mean that we should switch everything over to annotations. Everything in moderation, otherwise we'll be campaigning for the return of the web.xml file in a couple of years! ;-)