Over a million developers have joined DZone.

Is It Just Me: Fear Of Over-Annotation

DZone's Guide to

Is It Just Me: Fear Of Over-Annotation

· Java Zone
Free Resource

Learn how to stop testing everything every sprint and only test the code you’ve changed. Brought to you by Parasoft.

I was reading the new Java Servlet Specification (3.0), especially the "inevitable" sections dealing with annotations.

There have been quite a few blogs and articles around showing different opinions about pros and cons of the actual annotations in the spec.

But I have a feeling about annotations that's getting stronger over time: is the use of annotations as proposed by the various specs always leading to the desired result? Is it the only solution to the addressed problem? Is there possibly some overuse?

Another example I remember is the WebBeans spec that introduced Meta-Annotations. When will we start getting Meta-Meta-Annotations? This is somehow fun: it reminds me of the UML introduction of another level of meta and ot smalltalks meta-object-class. I really like meta but, anyway, back to the servlet spec.

Right after the section about annotations is the section dealing with web.xml and web-fragment.xml and the various rules which control the use of annotations and/or web.xml and/or web-fragment.xml.

Excuse me! What?! Maybe I'm a bit old fashined but I guess that set of rules introduces a bit of unnecessary complexity. Think of real-world software-projects... more options means more discussion means more... However, let me state this here: I'm not completely against annotations. I rather like them, if they're used in a sound manner.

For example, take the ServletFilter-Annotation. It requires the developer to provide a Path-Mapping Parameter. That means the Filters path is fixed at development time. Hmmm, is it just me to whom this sounds strange? Where are the good old times of the clean separation of concerns that Sun defined when coming up with J2EE: development vs. deployment. Yes I know: annotations are a great help to developers that want to do some rapid typing. But what I see here is that this annotation of ServletFiler is JUST a simple workaround for...

a.) ...developers who refuse to edit two seperate files (the filter.java and the web.xml) and/or

b.) ...tool-vendors who have not come up with the idea to have cleverly linked source code editors which really would make life easier.

I think especially point b needs some clarification. Think of a clever, context-sensitive IDE toolset, especially editors which allow to link two files (the filter.java and the web.xml) together in ONE editor-view.

Say you just typed "extends ServletFilter": I have an editor in mind which automatically links a view of the web.xml into the java source code. No need anymore to switch between files but still the best of both worlds: ease of development through directly typing in meta-infomarion and still seperate source and deployment artefacts.

Source Editor with web.xml section Such an intelligent editor could look like the picture above, yes of course it has to look a lot prettier, but I'm an developer, not an artist ;-)

So how does this look to you? It's pretty much like annotations but without annotations. The develper is not forced to switch to another file or view like in pre-annotation times: whether it be the web.xml itself or the web-wizard. The developer is able to type in stuff and in the background the intelligent editor routes the various pieces of information into the file where they belong. By the way: I would very much prefer to see the notion of "deployment environment" that I'ver tried to sketch with the tabs "Development Config" to "Productiv config". Those environments must somehow be configurable, that would have been a big points addressed in servlet spec.

So this is may case against annotation-overuse in favor of intelligent development tools.

What do you think?

Get the top tips for Java developers and best practices to overcome common challenges. Brought to you by Parasoft.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}