Spring @Autowired usage

Question

What are the pros and cons of using @Autowired in a class that will be wired up by Spring?

Just to clarify, I\'m talking specifically about the

Answer 1

I really love write with annotations, instead of XML. According to the Spring manual and the last versions, XML and Annotation achieved the same result.

This is my list

Pro:

• Remove useless line from xml
• Simplify the debugging the code: when you open a class, you can read what you have in the class
• More fast developping, a project with 400 or more line of XML is readable?

Cons:

• Is not standard Java implementation, but you can switch to use @Inject, which is a Java Standard Api, so the bean remain a Pojo
• You cannot simply use everywhere, db connection e so on, but it's only an opinion, i prefer have a place where read all configuration.

Answer 2

There has been very little discussion about switching environments. Most projects I've worked on it was a real issue to inject dependencies depending on the environment we are working on. With xml config it's pretty straightforward with Spring EL, and I am not aware of any nice solution with annotations. I've just figured out one:

    @Value("#{${env} == "production" ? realService : dummyService}")
    private SomeService service;

It should be working, but not a nice solution imho.

Answer 3

I have switched to @Autowire. Maintaining the XML configuration on anything other than a small project became a task in it's own right and comprehension quickly degraded.

IntelliJ provides good (not perfect) support for Spring annotations.

Answer 4

For my understanding @Autowired is the best to use while refer to interface reference and use its override funtions, but I only find issue with this is that it sometimes assigned to null at runtime.

Answer 5

For me here is what I like/dislike about Spring and auto-wiring.

Pros:

• Auto-wiring gets rid of nasty XML configuration.
• Much easier to use annotations which allows you to inject directly using fields, setter methods, or constructors. Also allows you to annotate and 'qualify' your injected beans.

Cons:

• Using auto-wiring and annotations makes you dependent on Spring libraries where as with XML configuration you could chose to run with or without Spring. Like you said, you become tied to a DI framework.
• At the same time I like being able to 'qualify' beans, to me this makes the code really messy. If you need to inject the same bean in multiple places, I've seen the same string name repeated all over. To me this seems to have the potential for errors.

I've started using auto-wiring almost exclusively at work because we depend so much on Spring integration anyway that the dependency issue is moot. I worked on a Spring MVC project that used auto-wiring extensively and was a little hard to wrap my head around.

I think auto-wiring is an acquired taste, once you get used to it you realize how powerful, easy, and much less of a headache it is to work with than the XML configuration.

Answer 6

My take on this subject is that, xml configuration reduce the clarity of the code, especially in large systems.

Annotations like @Component makes things even worse. It steers developers to make objects mutable, as dependencies can't be made final anymore, given that default constructors need to be provided. Dependencies need to be either injected through public setter, or uncontrolled through @Autowired. [even worse dependency injection is compromised with classes that instantiate their dependencies, I still see this in newly written code!]. By uncontrolled I mean, in large systems, when multiple implementations (or children) of the type are available, it gets much more involved to understand which of the implementations was @Autowired, a complexity that makes investigating bugs much harder. It also means that, supposedly you have a profile for test environment and another for production, your production bugs will only happen when it hurts most - in production, rather than being able to spot the bugs in the test environment, or even better, at compile time!

I stick to the middle ground where I declare my configuration class(es), (java based Spring configuration using @Configuration)

I declare all my beans explicitly in the configuration class(es). I only use @Autowired in the configuration class(es), the purpose is to limit dependency on Spring to the configuration class(es)

The @Configuration reside in a specific package, that's the only place where the spring scan runs. (That speeds up start time substantially in large projects)

I strive to make all my classes immutable, especially the data object, JPA, Hibernate and Spring, as well as many serialization libraries seem to undermine this. I steer away from anything that forces me to provide setters, or remove the final keyword from my property declaration.

Reducing the possibilities of changing objects after they're created, reduces substantially the bugs in large system as well as reduces the time to find a bug when one exists.

It also seems that it forces developer to better design the interaction between the different parts of the system. Problems and bugs become more and more compilation errors, that reduces wasted time and improve productivity.