Return to Answer

But, for me, they share the same concerns. And, my favorite, the constructor injection:

But, for me, both share the same concerns. 

And, my favorite, the constructor injection:

1. Prevent circular dependencies: Spring is able to detect circular dependencies between the Beans, as @Tomasz explained. See also the Spring Team saying that.
2. Dependencies of the class are obvious: The dependencies of the class are obvious in the constructor but hided with field/setter injection. I feel my classes like a "black box" with field/setter injection. And there is (by my experience) a tendency to developers not bother about the class with many dependencies, that is obvious when you try to mock the class using constructor injection (see the next item). A problem that bothers the developers is most likely to be resolved. Also, a class with too many dependencies probably violate the Single Responsibility Principle (SRP).
3. Easy and reliable to mock: compared to Field injection, it's easier to mock in a unit test, because you don't need any context mock or reflection technic to reach the declared private Bean inside the class and you will not be fooled by it. You just instantiate the class and pass the mocked beans. Simple to understand and easy.
4. Code quality tools can help you: Tools like Sonar can warn you about the class getting too complex, because a class with a lot of parameters is probably a too complex class and need some refactor.
5. Better and independent code: With less @AutoWired spread among your code, your code is less dependent of the framework. I know that the possibility to simple change the DI framework in a project not justify that (who does that, right?). But this shows, for me, a better code (I learned this in a hard way with EJB and lookups). And with Spring you can even remove the @AutoWired annotation using constructor injection.
6. More annotations is not always the right answer: For some reasons, I really try to use annotations only when they are really useful.
7. You can make the injections immutable. The immutability is a very welcomed feature.

1. Prevent circular dependencies: Spring is able to detect circular dependencies between the Beans, as @Tomasz explained. See also the Spring Team saying that.
2. Dependencies of the class are obvious: The dependencies of the class are obvious in the constructor but hided with field/setter injection. I feel my classes like a "black box" with field/setter injection. And there is (by my experience) a tendency to developers not bother about the class with many dependencies, that is obvious when you try to mock the class using constructor injection (see the next item). A problem that bothers the developers is most likely to be resolved. Also, a class with too many dependencies probably violate the Single Responsibility Principle (SRP).
3. Easy and reliable to mock: compared to Field injection, it's easier to mock in a unit test, because you don't need any context mock or reflection technic to reach the declared private Bean inside the class and you will not be fooled by it. You just instantiate the class and pass the mocked beans. Simple to understand and easy.
4. Code quality tools can help you: Tools like Sonar can warn you about the class getting too complex, because a class with a lot of parameters is probably a too complex class and need some refactor. This tools can't identify the same problem when the class is using Field/Setter injection.
5. Better and independent code: With less @AutoWired spread among your code, your code is less dependent of the framework. I know that the possibility to simple change the DI framework in a project not justify that (who does that, right?). But this shows, for me, a better code (I learned this in a hard way with EJB and lookups). And with Spring you can even remove the @AutoWired annotation using constructor injection.
6. More annotations is not always the right answer: For some reasons, I really try to use annotations only when they are really useful.
7. You can make the injections immutable. The immutability is a very welcomed feature.

Well, this seems a polemic discussion. The first thing that needs to be addressed is that Field injection is different from Setter injection. I already work with some people that thinks Field is equals to Setter injection.

But, for me, they share some of the concerns. And, my favorite, the constructor injection:

I have the follow reasons to believe that the constructor injection is better than setter/field injection. I will quote some Spring links about this subject:

If your are not really sure about the advantage of constructor, maybe the idea to mix setter (not field) with constructor injection is a option, as explained by the Spring team:

Well, this seems a polemic discussion. The first thing that needs to be addressed is that Field injection is different from Setter injection. I already work with some people that thinks Field and Setter injection is the same thing.

But, for me, they share the same concerns. And, my favorite, the constructor injection:

I have the follow reasons to believe that the constructor injection is better than setter/field injection (I will quote some Spring links to demonstrate my point):

If your are not really sure about the advantage of constructor, maybe the idea to mix setter (not field) with constructor injection is an option, as explained by the Spring team: