Are annotations bad?


I eased off into this topic with my principles on my post about Spring XML vs. Annotations that other day. This easy inlet was also my way of not complicating things too much for my team who is currently involved in writing this new app that will probably have a production life-span for 3-5 years (if we do it right and hope world of technology does not changes over it’s head).

I have been working with Spring Days since 1.1 so yes I have a level of comfort working with very large and complex XMLs. But, 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 – Spring STS with Beans Explorer /Graph. Developers now do not have the need to worry about looking at multiple XML – those tools do the job for them 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, and 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 point that this feature has been anything but abused by the community to it’s core and Spring has been guilty of promoting the abuse. Any Spring Documentation today, talks about annotation-style’d coding only to follow with the “classic XML way” of doing things.

While people say – it’s easier to read the Code, it’s easier to debug the code with annotations in the mix, they forget what’s it’s not code in code anymore – they have embedded configuration in code. And as far as I 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 are not what spring was design for. It’s time for me to go find what Rod Johnson had in his mind when he designed Spring (I know a bit but I need to find some details and get into 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 use, but very soon we realize that but using these so called Rich Annotation based configurations in Code we have diluted the overall meaning of What code/design is supposed to be. This style of programming is great when I have to try something new as 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 how do 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 hardly put in context 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 which we were trying to retrofit into Hibernate and something that was possible to write in MS-SQL as optimized procedures and fire away those queries were now becoming major bottleneck. I was new to the framework but more importantly I had a push from my technical leadership to use Hibernate to it’s fullest. Those people had access to article like I shared earlier and this looked like the way to go but they were nothing but marketing material to sell a feature that Hibernate and ORM brought onto the table. When rubber hits the road is when i had to go back and refactor the code and follow good old ways of writing queries.

90% of the times these frameworks that use annotations work well, but those 10% where you need your system to perform under stress is EXACTLY when these fail

Back tracking to Spring and Annotations now – why i do not like them? Simply because they make me write code like I am a college student who is learning something. 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 bunch of classes and it used to take time to write the SQL queries but I had right stuff in right places. And Yes it took time before we gathered momentum, but once we had those basics setup tight not only we could development speed, we also had done the things the right ways.

And yes no one can force us, but the average Joe Developer or the average Jim architect do not have the time and inclination and make these POVs, 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 many a times challenge the POV of what I am trying to put here.

TLDR;

Think about it and please do not use annotations to configure your applications. Configurations were never meant to be part of code – the reason they are called configurations. So let’s let those be. A small gain in short term wont go the long way especially when a client asks for a change in a table or a value and you tell him that will beed 5 days of development, testing and deployment.

Advertisements

8 thoughts on “Are annotations bad?

  1. What is exactly the point of configuring everything in XML when there’s only one choice (i.e, a bean) available? This can easily be done using annotations, and if a real option appears, one can extract the annotation to XML and actually make it configurable.

    Furthermore, I’m curious what you mean with ‘90% of the times these frameworks that use annotations work well, but those 10% where you need your system to perform under stress is EXACTLY when these fail’. Annotations don’t exactly mysteriously disappear when a JVM is under heavy load. What frameworks fail in their configuration under stress?

    The same goes for ‘We sacrifice the art of writing good and performant code for the short term gains of improving developer productivity’. What does annotation- or XML-based configuration have to do with performance? Both will be read during deploy. Sure, maybe in some cases annotations will be slower, but I can’t imagine that this will actually be noticeable.

    I think you are insulting a lot of people by saying that working with annotations makes you feel like a college student.

    It is not that I’m a opponent of XML, but I’m a proponent of keeping things simple; which in my case means that I use annotations wherever possible, *unless* it is actually changeable, and therefore configurable.

    • hello FDJ, you are right, that XML is done the way Spring (as a framework) suggests are just as bad as Annotations (if we take that as an example). There are 2 levels of problems here:

      1. In Annotations when you Autowire a bean you are stuck with it and any changes to a different implementation of that interface needs you a code compile while;
      2. In XML, you can put all the ‘configs’ in a separate project which your code can read and when you need to go over to a different implementation, at least you dont need code compilation. yes you might need a change in config and a restart but you know nothing else is broken. I think of JVM config changes where we don’t change code when we have to say take verbose dumps, etc.

      I hope this example clarifies why i feel XML based configs are better than annotations. I am big Spring fan and have been using it for 11 years now. But, for last few years everytime i see a code come to me by my team it’s all annotations. and when i explore with them it always comes back to “there are 100 articles that tell me to do this way…”.

      Yes, they can write code quickly and they can get the job done but when i have to make changes to a simple config, it later comes to “oh that is a code change and now it needs a release cycle..” thats what we sacrifice when we pick annotations.

      As for Stress, i was referring to specifically Hibernate and the explosion of annotations in there. With annotations, I have seen people write queries and use hibernate’s to generate (o)SQL. yes that can happen in XML too, but JPA more recently has flooded the need of not writing SQL queries but drop in Entities to do that. We had some control with configurations (not a whole lot), but annotations are just making people move away from writing stored-proc or better queries where they were supposed to be (i still love the Spring DAO project in it’s initial stages).

      I am sorry to say mate, but a lot of people do this. I dont want to insult everyone because sometimes someone needs a quick start project. I myself use these methods but not in enterprise (always when I am trying to build something real fast as POC, these are great). I meet several professionals who are mis-guided by these practices over the internet. I am sure people don’t have wrong intentions, and these tutorials are to help people learn and learn fast. But, people think “this is the only way to do it…” that is a problem with these articles.

      And, yes annotations are not bad. I use them myself (there will be more posts around some good ways to use in coming weeks).

  2. I think you are missing the point. Annotations are not meant for configuration – and are mostly not used as such. They are what the name says: a tool to describe what your code is meant to be. Like, for example, that a class is meant to be used as a @Service, a @Controller or another type of @Component. Or that you expect a certain method to always execute in a @Transactional context. Or that you expect the environment to @Inject or @Autowire some dependency for you. Or that you do expect a certain method to be called with a @Nullable argument, or one that’s always @NotNull, for that matter. That’s all there is to annotations – they add descriptive/expressive power to the language.

    Now, if you’re precise and consistent in describing your code using annotations, Spring, or any other dependency injection framework, for that matter, can figure out how to compose an application of formally uncoupled, or at least loosely components. This mechanism has nothing to do with the way more precise and detailed wiring mechanism provided by Spring XML-based application wiring. With XML, you really need to tell each and every piece of your application what exactly each of its collaborators are. XML in fact doesn’t relieve you from thinking of your application in terms of a large monolith, the same way you’d do it without Spring – it just moves part of this thinking out of Java code into XML.

    XML per se isn’t bad – after all, people have been doing monoliths for decades, and still do them, in the age of REST, cloud computing and microservices. Only, it doesn’t scale. The problem with large monoliths, typically found in enterprises, is that the part of thinking being moved out to XML becomes so complex that it’s no longer any easier to do it in XML than in code. What helps here is to relieve the programmer from doing this thinking, and let the computer do it. Here’s where annotations come into play. The programmer no longer thinks about wiring, he merely has to provide a proper description of his component, via annotations. The hard thinking about what to wire to what, and in what order, is done by the computer, via a complex, thorough analysis of all descriptions available to it.

    True, leaving it all up to the computer is risky. The computer might make wrong assumptions, component descriptions using annotations may contain errors, some things might combine in unexpected ways at runtime. But on one hand the analysis process performed by the computer on all annotation-based descriptions is very thorough, very much like a compiler does on code, and is able to generate good descriptions of problems early on, when you start the application, and second, as with any complex body of code, be it with or without annotations, with or without Spring XML configuration, thorough testing is paramount.

    • Thanks for reading and responding in such a detail.

      You are right that annotations by themselves are not evil; the issue lies in the fact that how they are used. You yourself described very well what they should be and if defined right then frameworks like Spring, etc. can pick it up and attempt to construct the behavior. What I have seen is that this construct is abused to a point when it’s an issue now.

      As i explained in one of my previous comment as example, annotation based configuration (by convention as we call it), makes me us do things in the wrong manner. I also understand that this construct/method came up to relieve a developer of the monolithic XML approach but what that has led to is a side effect when they now write something which is not only rigid but in cases (like hibernate) is non-performant. Why that happens as I understand is because they are still learning and are junior developers (most part) and they follow what is exposed on internet as examples and starter guides.

      Now we wanted to relieve them of managing the monolithic XML approach, but we now are asking them to make decisions when to use XML vs. annotations and make judgements. I saw a code recently which was on Spring-JPA-Hibernate and someone had used @Entity annotation and on that annotation they had the db schema name hard coded. The point being they can’t think of that fact that a schema name may change from environment to environment say when i am repurposing the same DB server to save on setting up 2 instances – bad design. this should be configurable. Now if this was in XML, by design it would not need a code compile and redeployment, but annotations now need me to do that.

      The idea that monolithic XML were a problem is something of the past, we now have tools like Spring STS where we can now visualize and manage beans and their relationships. I can see the argument that this is only with Spring and what about others – maybe. So I would think when we have tools where XML can make sense via tools we should at-least stick to it there.

      I guess the annotations are not evil, but I them being an instrument that can lead to evil usage.

      • @Introduction
        Your article makes me so confusing 🙂 and I think it takes a wrong point of view for a known issue about configuration in Java (especially in the EE world) and a general abuse of some instruments such as Annotations.

        @Body
        It’s a very generic discussion: when you start to feel comfortable with a kind of development, it’s really hard to get rid of it, both XML and Annotations. There’s no “I’m a rookie” or “I’m a ninja-kaiju”, you are always going to face someone who will tell you “I think it’s better in this way not that”. Why? Because there’s no convention in programming (I don’t mean good practice, since is a very different concept).

        ORMs are evil? It depends. Annotations for configuration (but they are not for that) are evil? It depends. XMLs for data-exchanging are evil? It depends. All such assumptions on what kind of instrument/framework is good for your work depends on a lot of things. For such reason I never trust an article that starts with a title like this: “Annotations are evil” and ends with “because they make me write code like I am a college student who is learning something”.

        @Ending
        What makes me dizzy about it is there are a lot of articles like this that lead to a general confusion only. And this is much more dangerous than an abuse of Annotations.

      • Fair enough Trylo. I have realized (across so many comments i received) that I may have generalized the situation too much. I will post an update on this with a revised wording and hopefully explain my POV a little better.

  3. While I would have agreed wholeheartedly some years ago, I have actually grown accustomed to the annotation-based approach. Nowadays, I’d agree with Michael Russo – while it is important to externalize configuration, I simply don’t view the wiring of my classes as “configuration” anymore. I think that seeing program structure as configuration is something that Spring itself created – and it wasn’t as good an idea as I thought initially, to be honest.

    The part of the post that I do still agree with, though, is the one about ORMs like Hibernate. I think that those are the single most overrated development in software technology thaqt I’ve dealt with in the last 20 years. While I initially thought that this kind of framework could be quite useful im some cases while being more or less superfluous in most others, I now know that ORMs never solve a problem. They don’t even shift it to a different layer. They simply change the notation, dumb down the software and introduce hard barriers for performance and scalability. Today I dare to say that there is absolutely no problem thaqt can be solved with an ORM that can’t be solved faster, simpler and more maintainable using straight JDBC/SQL. Not a single one. And it doesn’t even matter if you use Hibernate with XML or annotations – it’s bad both ways.

    Yes, I am a very old man (I’m 40) in a business where many people are much younger. When I utter my views on ORMs I often get accused of being a stubborn old man who can’t keep up with the world anymore, especially as some are very convinced that NoSQL is the only solution to any conceivable problem, anyway. I don’t think that, though. I generally like new stuff, be it in hardware or software. I just don’t think that Hibernate does a better job than me when it comes to mapping my OO design to a relational storage model. And every time I see the kind of SQL an ORM emits, I know for a fact that I am right.

    • Thanks George for taking the time to respond. I have seen Michael’s response but am unable to post a reply on JCG for some reason the Captcha fails!!

      It seems in my post i err’d on the side of generalizing everything and I agree that’s not a good practice as I only do what I am trying to avoid here. I agree wiring of classes generally if a case where annotations can be used. Yet, there are cases where Spring-style wiring just doesn’t work. I am working on an example to document that and explain where wiring doesn’t works. But, yes thats that 2% exceptional use cases.

      The problem I have is that people ignore those use cases and we pay for it in production during maintenance and upgrades. I will work on a few more posts to explain my POV around this in detail.

      thanks again for reading and commenting. you all encourage me to write more and more 🙂

Initiate your idea here...

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s