This post originated from an RSS feed registered with Java Buzz
by Norman Richards.
Original Post: Why you should configure with annotations
Feed Title: Orb [norman richards]
Feed URL: http://members.capmac.org/~orb/blog.cgi/tech/java?flav=rss
Feed Description: Monkey number 312,978,199
While there are still a few Luddites who refuse to use annotations, the Java community seems to have come to grips with them and we're seeing more and more use of annotations in application development. Whenever annotations come into play, the biggest concern is always when to use them.
Andy has a nice post explaining when annotations make sense over over external (XML) configuration. I don't disagree at all, in the general sense, but I've recently been swayed even more by the power of annotations so that I actually think configuration is perfectly fine in annotations.
Yeah, I said it. But before the stones come, let me explain what I mean. I think it makes perfect sense to put the default configuration in annotations. It's a perfect fit for this information. What if you need to make a configuration change at runtime? I think EJB3 solves this problem well by allowing you to fall back on an external deployment descriptors to override annotated configuration. Perfect. As long as the option exists to override form an external definition, I wouldn't hesitate to annotate nearly every detail. The problem is that there isn't a standard way of doing this yet. You are at the mercy of whoever is interpreting the annotations. The JCP needs to get on this.
If you aren't throwing stones yet, I'll go a step further and utter the ultimate heresy. I think you should annotate your ORM mapping details right into your model classes. I know many people hold this up as the definitive example of what you should never annotate into your class, but I disagree. It's a perfect use of annotations.
Let's be honest, the mapping details don't change often and they almost never change at deployment time. Your persistence engine can handle the differences between databases such that one set of mapping details will work for almost any environment. I have no problem with @Table or @Column or any of the other entity annotations. The beautiful thing is that for that very, very rare case where you do need to change the mapping after development, you've got the ability to override with an external mapping file. But, why saddle yourself to external mapping files until you actually need them?
What about re-use? Don't annotations inhibit re-use? Ok. That's certainly a downside. If you need to use the same class in two different contexts, many annotations that would otherwise make sense don't. The good news (or perhaps the bad news) is that re-use doesn't happen much. Let's be honest. You spent all that time writing re-usable libraries and components because that's the thing all good coders do. But admit it, you didn't end up re-using any of the real application code, did you? It's not impossible, but I find it pretty rare. I've been through enough customer code to know that my personal experience is the norm and not the exception.
If you are actually re-using components then annotations buy you a lot less. You have to do a lot more work with external configuration. But that's really fine. If you are doing the harder, less common thing you have to work harder. If you are doing the simpler, more common thing, annotations make your life so much simpler.
I've been very pleased with the results of liberal use of annotations, but if you aren't convinced then then stick to Andy's recommendations. It's a very practical approach that won't lead you wrong.
Previous Topic
