Am I too stupid for @Autowired?

When I started with Spring, I finally had the feeling that I could write enterprise application in the same powerful way as I could write normal systems. And I have written quite complex Java stuff like expertsystems, prolog compilers and various other compilers and interpreters and currently working on Multiverse; a software transactional memory implementation. I also have written quite a lot of traditional enterprisy Spring applications (frontend, backend/batch processing). So I consider myself at least as smart as most developers.

The first applicationcontext files felt a littlebit strange, finding the balance between the objects that need to be created inside the application context and objects created in the Java objects themselves. But it didn’t took me long to find this balance and realise how powerful the application context is:

  1. it acts like a executable piece of software documentation where I can see how a system works, just by looking at a few xml files. I don’t need to look in the source to see how stuff is wired.
    I compare it with looking at Lego instructions, by looking at the instructions I can see what is going to be build (not that I ever followed the design). To understand what is build, I don’t need to look at the individual parts.
  2. separation of interfaces and implementation, so testing and using a lot of cool oo design stuff is a dream
  3. having the freedom to inject different instances of the same interface on different locations. This makes it possible to do cool stuff like adding proxies, logging etc etc. I wasn’t forced to jump through hoops any more because of all kinds of container specific constraints

With the old versions of Spring (1.2 series) I had the feeling of total control and complete understanding.

The application context made me aware that I needed to work with 2 hats:

  1. ‘Object’ designer; so actually writing the Java code and documentation
  2. ‘Object’ integrator; where I assembly complete systems based on the objects

And I loved it.. I have more than 1.000 post on the Spring forum just because I believe in this approach.

But if I look at a lot of modern Spring applications, filled with @Component and @Autowired annotations, it feels like I have lost it all. It takes me a lot longer to realise how something works, even though I have a great ide (newest beta of IntelliJ) with perfect Spring integration that makes finding dependencies a lot easier. So I keep on jumping from file to file to understand the big picture. A lot of developers I meet/work with think that the auto-wiring functionality is great because it saves them a lot of time and prevents them from programming in XML (XML was a bad choice, but that is another discussion), but somehow my brain just doesn’t get it.

So my big questions are:

  1. am I too stupid?
  2. if I’m going to try it longer, am I going to see the light?
  3. do I expect too much? So because less characters need to be typed, is it inevitable that some redundant/explicit information is lost
  4. is this some hype and eventually people start to realise that it was a nice experiment, but doesn’t provide the value it promises (just like checked exceptions or EJB 2). And in 10 years we can all laugh about it.

20 Responses to Am I too stupid for @Autowired?

  1. John B says:

    I tend to agree with you. Annotations are great, and speedy for development, but are much less helpful when trying to learn how code works.

    Having ‘onboarded’ people into code with applicationContext.xml files and annotation based code, I think having the XML in place as a type of outline for the application is quite helpful for folks new to an application, and is much easier to talk about than jumping between 50 different files to show how code hooks together.

  2. Costin Leau says:

    Hi Peter,

    Configuration through annotations is just another way of instructing the container what to do (Spring is not the only one supporting this). From my experience, its effectiveness depends a lot on the application conventions. There are teams which prefer working just in Java and having the configuration coupled in the sources, especially if they are familiar with the project.
    Configuring through XML is still an option – it never went away – you can always use the “1.2 style” (as you call it) and it works great for environmental configurations or keeping the config in a central place.
    In Spring 3.0, there’s also the ‘@Bean’/JavaConfig support which gives a strong-typed configuration w/o ‘tainting’ the code in any way (see for more info).

    Anyway, my point is that annotations/@Autowired/@Resource are not a ‘better’ way of configuring applications, just a popular alternative (it’s entirely possible to mix and match them, if you want).


    • pveentjer says:

      Hi Costin,

      my big question is if they are also able to form a mental picture of the system using annotations and autowiring. Perhaps they are able to and I’m not, or perhaps they don’t care about it and I do.

      I know that xml-configuration is still an option but some kind of consensus is needed on the project(s), so that not ever project uses a different approach. Atm almost everything is done using autowiring (I even see code that has no setters/constructors at all but everything is done using autowiring, and this makes even testing annoying because reflection needs to be used). In my humble opinion is that the code is less healthy than it could be.

      I work for a company that relies on external parties to do a lot of the implementation, so we need some kind of guidance. I have recently joined the company as one of the hands on architects and I’m experiencing a slow down because of the autowiring which makes simple systems needlessly complex. So I need some advice on how to tackle the problem (even though I don’t have a lot of developers/architects sharing my opinion).

      • Costin Leau says:


        In your case, since autowiring and annotations are used, I would recommend looking at the latest SpringIDE/STS (2.0.0+) which adds support for @Autowired so one can visualize the full application context.
        See STS new and noteworthy for more info – (page 5).

        Another approach of course, if you are uncomfortable with the autowiring/annotations to try to “lock” down the core aspects by “centralizing” them somehow (use naming conventions for classes or packages).

        Hope this helps

      • pveentjer says:

        Hi Costin,

        moving to a different ide, just because of the choice between classic-wiring and auto-wiring doesn’t really sound like an viable option, don’t you agree. And a lot of developers at my company prefer IntelliJ (almost all are using it).

        I have checked the presentation of Alef, and I guess I’m not the only one that still finds an explicit application context (either Java based or XML based) still usable.

      • Costin Leau says:

        I’m not using IntelliJ myself (but Eclipse/STS) so I don’t know whether they support @Autowired or not – I imagine if not, they will at some point in the future. What I can tell you for sure, is that STS does and can be used until other alternatives that suite your project appear.

        As for XML and JavaConfig – they are great for centralizing and I personally still use them a lot – however, my understanding is that the decision has been already made in your project that’s why I was pointing out ways to better edit and visualize the configuration.

  3. Mark says:

    As with anything, they need to be used wisely. I have been using annototions with services and repositories because those are pretty obvious and greatly simplify configuration. Other things I like to wire up in XML.

  4. Solomon says:

    I see this issue as one ripe for a good solution… SpringSource? MyEclipse? IntelliJ? Anyone listening?

    • Costin Leau says:

      Hi Solomon,

      As I’ve just mentioned in previous comment, STS 2.0.0/Spring IDE supports editing/validation and visualization of @Autowired based configurations – see the link in my previous comment.

      As for listening, please report the issues/improvements on the SpringSource tooling forum or bug tracker so that Christian and team can take a look at them – We’re trying to follow “the net” (as you can see) but as you can imagine, it’s easy to miss things.

      Costin Leau

  5. Sam says:

    It’s understandable you feel that way, but when you declared everthing you’re doing in xml you are being redundant. It would be (almost as clear and)just as easy writing down everything my code does and what components it uses to do it in plain english.

    I do grails development so I don’t see even @Autowired annotations and yet however I can easly and quickly understand the code most of the time.

    Thats’s what code is for, telling me what it is doing.
    We always try to be as clear as possible and as a last resort use comments.

  6. bqlr says:

    you never refactor? auto wire is a great function, please check my framework jdonframework (, it’s autowire function is early than spring 2

  7. Sakuraba says:

    I think that “Autowired” is not good by definition. Whenever something happens automatically in the background without being explicit for everyone to see, it is bad. I like the approach that Guice has gone, where you have the “wiring”-part in a Java-DSL:

    public class BillingModule extends AbstractModule {
    protected void configure() {

    It is more concise as XML, it is explicit and has the advantages you spoke about earlier.

  8. Andrew Phillips says:

    I certainly agree with Peter that the XML configuration has additional value as a ‘structural’ or ‘architecture’ reference (or however you want to describe it), and is also a good starting point when trying to get to grips with an application, as John B points out in his comment.

    However, as applications get bigger, my experience at least is that, firstly, the relative number of people wearing the ‘integrator’ or ‘architect’ hat significantly decreases. As more and more developers on the project only interact with the context in order to *maintain* the configuration, rather than *consult* it, the argument can shift towards using annotations for ease of use (whether they are *really* easier to use is another debate).

    Perhaps more relevantly, all of the large projects I have worked on that used XML configuration ended up with multiple XML files with complicated ‘include’ links – some for optional components such as aspects, others in order to be able to modify configurations for testing etc. Often, this reached a point where the application structure was no longer easily deducible for just the pure XML.

    I think Costin’s point is very valid here: beyond a certain complexity of the configuration, it is difficult to understand it without a specialised visualization tool (Spring STS in this case), in much the same way as it would likely be very difficult to understand a complex Java application just by looking at the files in a text editor.

    That IntelliJ does not apparently offer such a visualization tool yet is of course a pain point, but if one considers STS as a standalone “Spring analyzer” perhaps it is quite so crazy to consider running an Eclipse just for this purpose. Not nice, of course, but still.

    As regards XML vs. JavaConfig/Guice, I’m curious as to which will prove the more useful in expressing configurations. The typing and refactoring support of Java IDEs certainly helps, but then again with STS you also have that in the XML, if I remember correctly. Personally I find XML a bit more readable as it’s more declarative, but then again it’s a bit less flexible, too.

    One thing that *does* scare me is the idea of including the configuration for a component in the component itself, as in the following example from the Spring docs:

    public class FactoryMethodComponent {
    private static int i;

    @Bean @Scope(BeanDefinition.SCOPE_SINGLETON)
    private TestBean privateInstance() {
    return new TestBean(“privateInstance”, i++);

    public void doWork() {
    // Component method implementation omitted


    To me, this not only feels like mixing unrelated concerns. As a developer, I think I would also tend to read the bean definition as an implicit ‘contract’ – perhaps I should say “strong hint” – defining how the component should be used. But if FactoryMethodComponent should really be a singleton shouldn’t one enforce that in the object itself.

  9. elzinga says:

    I would vote for the java-based config (dsl-like). @Autowired is too confusing if there are multiple implementations, for example.

    Only for a limited subset of usecases autowired will work. Together with a lot of conventions. It will fail if any complex wiring is required.

    Just do what it is meant to do: dependency injection, as transparant and easy as possible.

  10. Jason says:

    Tools. Neither approach is good or bad. They are simply tools to do a job. When tools are misused, Bad Things can happen.

    You don’t HAVE to use one over the other. Use them where they make sense.

    From what I have seen, programmers (people who are in code a lot), tend to lean toward annotations because the information is in a place where they are comfortable: in the code. Architects/high level programmers tend to want to see everything in one place: the spring config files.

    I have used both. I have seen the benefit and limitations doing it both ways. The way you choose should be what makes you efficient and your team successful.

    One last comment: don’t forget about maintenance. 80% of the cost of software is in the maintenance. Who will maintain the code? Can they understand what is happening better by looking at annotated code or by looking at a spring config file?

  11. Leo Hart says:

    I also have an internal debate over externalized XML vs annotations. I’d say in principle I prefer the externalized XML because it’s…externalized…my classes have no knowledge of framework existence. I also like the fact that it shows how the whole system comes together, as you mentioned.

    The two things I don’t like is:
    1. When I’m developing, it forces me to leave my primary focus (classes that implement functionality) to go wire things together.
    2. A PITA when it comes to refactoring unless you use the sometimes-very-resource-intensive STS plugins.

    #1 I’m willing to deal with. I can always develop with annotations and then refactor to an externalized solution for the final solution.
    #2 I’m really interested in JavaConfig for these purposes. I think people think configuration and assume XML/properties, but as long as its externalized, Java seems great to me.

  12. Mustansar says:

    I am simply amazed over a this matters. There was a time we wanted to separate code from configuration. We started doing that. Later on we decide oh no! let’s start with @do this. I am not against annotations but wiring must happen outside to keep maintainers from beating initial developers. Frameworks got created to fix some problems now it seems like frameworks are becoming a problem in themselves. It’s just a comment I wish I had a solution:)

  13. […] 2 Dec 09 – Article about the thoughts on Spring’s @Autowired annotation […]

  14. […] Am I too stupid for @Autowired? – Peter Veentjer talks about his objections with Spring’s automagic functionality. I tend to agree that @Autowired is fairy dust in your code. And magic should be avoided when programming. […]

Leave a Reply

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

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

Google photo

You are commenting using your Google 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 )

Connecting to %s

%d bloggers like this: