The alternative is heaps of XML or JSON configuration, detached from the code where it’s used. Consider that if you wanted to inject a bean in Spring XML it requires creating a bean definition that in turn defines all the beans injected into it, which in turn require their own bean definitions, etc. Then you have to declare exactly which field/method the bean is injected into. If you were developing software in the pre-annotations day you’d understand how much that sucks. The annotation approach is much better in comparison.
Why not just use code (generated if required) to read xml or json for each class? That way it is clear, in the source code and can perform other transformations as required.
The whole point of spring XML was so you didn't have to "write code" to wire things up. Now we're using annotations to replace XML - we're writing code so we don't have to write code. It makes no fucking sense.
Annotation injections are a completely ridiculous turn of events.
> Now we're using annotations to replace XML - we're writing code so we don't have to write code. It makes no fucking sense.
It does though. Turns out that writing XML configuration means you don’t get to take advantage of the context associated with an annotation. I.e., if I put @Inject on method something(X value) in class A, all the context of what type to inject and where comes along for the ride. In XML I have to explicitly specify every single bit of context, and oh yeah, if I rename “A”, “X”, or “something” I better fix that in the XML or my program will blow up. Not a good look for a programming language that already gets grief about being overly verbose! Annotations just flat out make the configuration part of the equation easier.
Wiring up dependencies via XML is indeed a bad idea for the reasons you specify. But if you're going to wire up dependencies in code, you don't need annotations. Java already has a method for declaring and providing dependencies for a class: writing and calling constructors, which is clearer and checked by the compiler.
It's important to understand that spring gets around the wiring problem by being a system for declaring and using global variables. This turns out to be a fundamental waste of time, as the whole point of making things dependency-injectable in the first place was to avoid global variables.
However, every spring bean is a global variable, and every bean reference, whether explicit or implicit via autowiring, is a reference to a global variable. Spring results in bad, un-modular, hard-to-debug, and hard-to-maintain wiring code. Just say "no" to runtime dependency injection frameworks.
> I have to explicitly specify every single bit of context,
You still are doing that, just in a less clear way and a less debuggable way. Most other languages get along without meta-languages (there are some frameworks that are spring-like) because being explicit is better than being implicit.
> You still are doing that, just in a less clear way and a less debuggable way.
That’s debatable to a degree. If I put @Inject on a field it’s pretty clear what’s going on just from a quick glance of the source code. By contrast, I don’t know injection of some field happened _unless_ I take a gander at the XML config. And the debuggability of both approaches is the same, the injection manager is doing the same magic under the covers, only the configuration is different.
You can easily and correctly summarize Spring as follows. Spring tries to solve the problem of "applying parameters to function is boilerplatey" by creating a DSL for declaring and using global variables, because, global variables don't have to be passed around! And yet, ironically the reason we do parameter passing to functions (constructors factory methods, etc) is to avoid global variables.
Spring is a fundamentally flawed waste of time, and it represents one of the biggest mistakes of the Java community.
Consider that people to this day still dog Java for being overly verbose, and then consider how much boilerplate (code and XML) is required to make something like a Spring REST controller that includes dependency injection. You can boil that down to basically one small class with a couple of annotations these days. The old way is absolutely dreadful in comparison.
Annotations are great as long as the consuming framework reflects the annotations exactly once for JIT/bookkeeping. Often the people I see who hate annotations are invoking reflection (explicitly or implicitly) in critical code paths.
