The magic is in all the code that interprets those annotations. So you have to understand a large and complex framework to understand which objects are being injected (in Spring, for example, you have to keep in mind the rules about which beans are instantiated and then which of the instantiated beans are chosen for injection into a particular class), and to understand what actually gets injected (is it actually the object returned from the annotated method, or some proxy or chain of proxies adding additional behaviour to those objects?).
The principle of dependency injection is a good one, but dependency injection frameworks are an unnecessary and overcomplicated way of achieving it. XML-based DI frameworks at least had a rationale - the idea was to externalise configuration, so you could change the dependencies without changing the code. It turns out this kind of externalisation isn't actually valuable in most cases (changing the dependencies is just as complicated and risky as changing code, and often needs to be coordinated with more substantive code changes, so the separation is artificial).
Once you determine that you should wire up your dependencies in code, though, there's no need for dependency injection frameworks - you can just directly write the code that wires up the dependencies.
Can't see where this 'magic' comes from. IoC frameworks are not rocket science. Everything is very-well documented and pretty straightforward.
> dependency injection frameworks are an unnecessary and overcomplicated way of achieving it.
But why?
I don't want to write my own DI framework for each new project.
I'd better add one dependency, put some @Autowired (and other well-documented) annotations and continue writing business logic.
Aforementioned 'magic' is basically creating a context, scanning all annotations, registering beans, instantiating them (calling constructors), then injecting them.
As someone who recently worked on a spring project for the first time, it's pretty clear what magic we're talking about. I can't look at the code and know what the application does without first learning the meaning of a ton of different annotations and the behaviors connected with them. Annotations and the associated code are complex. Now that I understand what they all do, it's easy to reason about the app, but when I run it my mental model is still:
1. I launch the app
2. Spring does a bunch of stuff I only vaguely understand and can't understand from looking at the code
3. My actual code starts running
On top of that, all the spring stuff makes the memory footprint and startup time awful.
I wouldn't mind having things be created through autowiring and the like, if it didn't make it harder to make the things explicitly, without autowiring.
Ideally, making something automated should not make it harder to do the same thing manually.
Modern Java does fix that much. If you look at the `Sample` class from the example, it's a normal class that you can instantiate the normal way (passing its dependencies into its constructor) and ignore the annotations on, unlike the bad old days of afterPropertiesSet().
The principle of dependency injection is a good one, but dependency injection frameworks are an unnecessary and overcomplicated way of achieving it. XML-based DI frameworks at least had a rationale - the idea was to externalise configuration, so you could change the dependencies without changing the code. It turns out this kind of externalisation isn't actually valuable in most cases (changing the dependencies is just as complicated and risky as changing code, and often needs to be coordinated with more substantive code changes, so the separation is artificial).
Once you determine that you should wire up your dependencies in code, though, there's no need for dependency injection frameworks - you can just directly write the code that wires up the dependencies.