This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
The question is actually a difficult one to answer in a short answer.
Basically, there are pros and cons to all forms of configuration. Annotations, xml or Java Based Configuration. All the pros and cons are 100% valid. The main goal them becomes consistency. Making sure everyone on your project follows the same rules.
It is also NOT a question of either or, which one over the other. Because you can use any combination of configuration options in your application. One or all three combined. You just have to make your rules and stick to them
So my personal opinion is. Remember this is all my opinion and not fact.
1) Annotations over all other because I can configure and code much faster (
2) Java Based configuration for those beans I can't annotate (They aren't my classes so I don't have the source to add an Annotation)
3) xml with what is left, or I need it complete externalized outside the package of my classes and I don't want to recompile and repackage. (Extremely rare, like it has never happened to me yet that I needed this)
I've played around with annotations in Spring, including building my own annotations. Annotations are definitely much less clunky than XML. However, they are a lot like magic, and it's easy for developers to lose track of how it works. Espescially when there are problems, it becomes hard for developers to figure out the problem. Annotations are super when they work, a pain when they don't
Making your own custom runtime annotations is tricky, and you need to have a very good understanding of how the bean lifecycle works to get it right. In hindsight, I wouldn't have built by own annotation for doing my own custom autowiring. The time I spent struggling with the BeanPostProcessor, and the complexity of the BeanPostProcessor that I ended up wasn't worth the few lines of XML saved. In the end, I ended up making my NamespaceHandler to encapsulate the spring xml that had to be imported into every module that used my framework anyways. So, I didn't gain much.
If you have a large team and a multi-module project, I would first build consensus on some guidelines around which annotations you would use and which you won't, and how to use the annotations. Also, I would stay away from custom annotations unless you are going to use it a lot.
Jayesh I am sorry about what you encountered previously. But Annotations shouldn't be that hard. You shouldn't have to create your own custom BeanPostProcessor. I would have used something like AOP and a pointCut expression that looks for your annotaiton. In this way, custom Annotations are a great solution. I have made custom annotations to really simplify my AOP in my code.
Also from a standpoint of standard Spring Annotations for configuration, if you have problems you get the same exceptions you would find with xml. Maybe the message is slightly different, but still very easy to find the problems.
Since Java adopted annotations, I’ve heard a lot of discussion around whether to prefer annotations over external configuration files (often XML) and vice versa.
I think the decision boils down to two criteria:
1) Can annotations simplify the metadata?
2) Can changes to the metadata break behavior in your application?
If annotations do not reduce the amount of metadata that you have to provide (in most cases they do), then you shouldn’t use annotation.
I think the more important thing to considered is whether a configuration change could break behavior or not. If not, then you can feel comfortable applying the change while the system is running in production. External config files are the best place for the metadata in this case because you don’t want to have to recompile your code to make the change.