I eased into this topic with my principles from the post Spring XML vs. Annotations the other day. This easy inlet was also my way of not complicating things too much for my team, who are currently involved in writing this new app that will probably have a production lifespan of 3-5 years (if we do it right and hope the technology doesn't change overnight).
I have been working with Spring Days since 1.1, so yes I have a level of comfort working with very large and complex XML sets. I know how to write them and more importantly I know how to read them. Since then Spring has made it easy for developers to understand them using Spring STS with Beans Explorer / Graph. Developers no longer have the need to worry about looking at multiple XML sets – those tools do the job for us, even writing and managing beans for them.
We sacrifice the art of writing good and performant code for the short term gains of improving developer productivity
Since I saw Spring 3.x introduce this notion of Annotation-based configurations, the hype train of using these annotations instead of using XML has been huge for at-least 7 years (if i remember correctly). I have not been able to make peace with this change in direction. Not saying it’s bad, but the truth is that this feature has been abused by the community to it’s core, and Spring has been guilty of promoting the abuse. Any Spring documentation today talks about annotation-styled coding only to follow up with the “classic XML way” of doing things.
While people say – it’s easier to read the code and it’s easier to debug the code with annotations in the mix. They forget that they now have embedded configuration in code. And for as long as I can remember, configurations were supposed to be externalized. The problem is more severe in cases where we use ORM frameworks like Hibernate and JPA.
Even in original Spring Design, even with XML I feel that how we setup spring applications is not what spring was designed for. It’s time for me to go find out what Rod Johnson had in his mind when he designed Spring (I know a some of what he intended, but I need to find out some more details and go in depth). But thats for another day.
So let’s look at this blog post that explains using JPA with Spring or read this StackOverFlow thread. Well, they both explain how to do it, but very soon we realize that using these so-called Rich Annotation-based configurations in code will dilute the overall meaning of what code/design is supposed to be. This style of programming is great when I have to try something new in a personal pet project to get off the ground quickly – I can just write a class, type a few annotations and boom, I am ready to do CRUD. But does this really works in enterprise level applications, especially given how we manage this in production.
These articles are nothing but a bunch of marketing/sales pitches that want us to go use these frameworks and new features, but they rarely put thing in the context of the complex situations we have to deal with in big production systems.
In 2007, we used Hibernate extensively on our project (with Spring 2.x with XML based configurations) and we realized very soon that we had taken the ORM framework beyond it’s limits. We had complex queries that we were trying to retrofit into Hibernate and we would fire off any queries that were possible to write in MS-SQL, creating a major bottleneck. I was new to the framework, but more importantly I had a lot of push coming from my technical leadership to use Hibernate to it’s fullest. Those people had access to articles like the one I shared earlier and this looked like the logical way to go, but they were nothing but marketing pieces meant to sell a feature that Hibernate and ORM brought onto the table. When the rubber finally hit the road, I had to go back and refactor the code and follow more time-tested ways of writing queries.
90% of the time, these frameworks that use annotations work well, but that 10% where you need your system to perform under stress is EXACTLY when these fail.
Back tracking to Spring and Annotations now – why don't I like them? Simply because they make me write code like I am a college student who is learning something for the first time and my professors don't want to make things too hard on me. They force me away from what used to be good practices in golden old days. Yes it used to take time to setup a few classes and it used to take time to write the SQL queries, but I had the right stuff in right places. And yes it took time before we gathered momentum, but once we had those basics setup right, not only could we development at a high speed, we had highly-performant and easily-modifiable code.
And yes, no one can force you to do it this way, but the average Joe developer or the average Jim architect do not have the time and inclination and make these systems the way I do. They do a google search and when they see 5 articles saying the same thing, they presume it’s the right thing to do and they proceed happily. And many of our senior technologists who also read these articles support the designs and disagree with my point of view in this articl.
My advice is not to use annotations to configure your applications. Configurations were never meant to be part of code—that's why they're configurations and not source code. So let configurations stay in the configuration files. A small productivity gain in the short term won't go amount to much when a client asks for a change in a table or a value and you tell them it's going to take five days of development, testing and deployment.