Does using annotations to inject dependencies remove the main benefit of dependency injection(external configuration)?

The configuration is still external, because it is outside where you define which implementation is going to be injected. Inside the class, you just hardcode the name of something the class depends on (which is ok, because this dependency is inherent to the class).

The configuration is still external, because it is outside where you define which implementation is going to be injected. Inside the class, you just hardcode the "name" of something the class depends on (which is ok, because this dependency is inherent to the class). This said, you can use XML to override the annotations of your code for the tests execution (you would have a specific XML application context for your tests) and specify which implementation you will inject.

Therefore, you don't need to change your code to run the tests. Take a look to this answer.

Well that's correct. Annotations are configuration inside the source code. Mainly intended when you have one class for each service.

If you have more than one implementation for a particular interface, then XML will be a better option. Also you can mix XML configutation with annotations.

The conventional way, that I heard last time from DI camp, is that in unit tests, you shouldn't use the DI framework. Rather, simply instantiate mock service yourself and set it to the host object test() PersonController contr = new PersonController(); contr. PersonService = new TestPersonService(); // testing contr This was hailed as the first and major achievement of DI, much to the puzzlement of people (like me) who don't get it.

See my previous criticisms: advantage of using applicationcontext. Getbean vs @configurable If the DI supporters in this thread reflect the new trend in DI camp, they no longer do unit tests that way; instead tests depend on DI too, with a test specific DI config. Then it's really no different from service locator pattern.

If the major feature of DI is moot, then what's the point? Your controller class perfectly illustrated that. It cannot be used outside Spring DI framework as a POJO.

There's nothing POJO about it. And nobody cares, rightfully. Same thing if your class depends on a service locator framework.

There are other features provided by Spring beans framework, none of them depends on DI; they can be implemented in a service locator framework just as well. Many people when defending DI the design pattern, are actually defending Spring the entire stack. You can actually use Spring as a service locator framework; Spring will not advertise this now, it's a blow to its main hype point; but it will once the hype weakens and it must appeal to the doubters.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.