Dumb Annotations
Posted by Mike Haller
on Thursday, January 22. 2009
at 10:57
in Java
I just read the article about the new Java Servlet 3.0 Specification over at dZone when it once again struck me: Annotations!I like annotations when it comes to the declaration of meta-information about a class, a method or a field. For example as a replacement for Marker Interfaces or to add valuable information to existing things, like JPA's Annotations for the opposite type of collections or references. Or JAXB's Annotations to define the names for XML Types when they should be different from the Class names. These annotations all make sense to me.
However, there seems to be a group of people out there, which either don't know the basic rules of externalization and configurability, or they know something the common developer doesn't. I'm confused about using annotations for parameterization:
@WebServlet(name="mytest",
urlPatterns={"/myurl"},
initParams={
@InitParam(name="n1", value="v1"),
@InitParam(name="n2", value="v2") })
public class TestServlet extends javax.servlet.http.HttpServlet {
....
}
This was the sample code presented in the abovementioned article. The points I'm trying to make are these:
- Definition of the servlet's name within the Servlet class. How the hell do I re-use this servlet class with a different name, e.g. when other parameters are used. The 'name' attribute of @WebServlet makes Reusability completely, well, undoable.
Okay. Now let's assume that the in 90% of the cases, you've got only one servlet and thus you can use some sort of default name and default url patterns. I can live with having ids, names and URLs in code, although I tend to feel negative about it. I want to have all URLs in a single place of the application. When an application is in production, say 10 years after it's initial release, the developers are most likely working on something else and are not reachable. The guys maintaining the application will have a harder time to find names, url patterns and parameters when they are distributed all over the code instead of in a single place, where they can start to dig deeper. People need a single place where they can start their support work. It's awfull to have to scan multiple locations, look into a lot of code etc. just to find out that the URL was misspelled or a parameter has a wrong value.
Similar thing with the names. If the default name is specified using an annotation and I need a second instance of the servlet, I probably have to overwrite the second name in the web.xml I assume. Then i've got the two same thing in two different locations: The name of the first instance is in the class's source code and the name of the second instance is somewhere in a web.xml.
Back to the main thing, and this is now the point where it hits me everytime:
- Definition of servlet's initialization parameters weithin the Servlet class. If, for some obscure reasons, i know the values of initialization parameters while writing class and know that they won't change, why should I use annotations to declar them? Why not just some static fields or hard code them anyway? What please is the reason to put those into annotations?
I wish the spec leads would have thought more about how the Servlets provide more information (programmatically) to the servlet container and more hooks and interaction possibilities, instead of inventing yet-another-bag-of-useless-annotations.
