Nicolas Frankel 
CDI worse than Spring for autowiring?
Email
Let’s face it, there are two kinds of developers: those that favor Spring autowiring because it alleviates them from writing XML (even though you can do autowiring with XML) and those that see autowiring as something risky.
I must admit I’m of the second brand. In fact, I’d rather face a rabbied 800-pounds gorilla than use autowiring. Sure, it does all the job for you, doesn’t it? Maybe, but it’s a helluva job and I’d rather dirty my hands than let some cheap bot do it for me. The root of the problem lies in the implicit-ness of autowiring. You declare two beans, say one needs a kind of the other and off we go.
It seems simple on the paper and it is if we let it at that. Now, autowiring comes into two major flavors:
- By name where matching is done between the property’s name and the bean’s name
- By type where matching is done between the property’s type and the bean’s type
The former, although relatively benign, can lead to naming nightmares where developers are to tweak names to make them autowire together. The second is an utter non-sense: in this case, you can create problems in a working context by creating a bean in it, only because it has the same class as another bean already existing in the context. Worse, autowiring errors can occur in a completely unrelated location, just because of the magic involved by autowiring. And no, solutions don’t come from mixing autowiring and explicit wiring, mixing autowiring between name and type or even excluding beans from being candidates for autowiring; that just worsens the complexity as developers have to constantly question what will be the behavior.
Autowiring fans that are not convinced should read the Spring documentation itself for a list of limitations and disadvantages. This is not to say that autowiring in itself is bad, just that is has to be kept strictly in check. So far, I’ve allowed it only for small teams and only for tests (i.e. code that doesn’t ship to production).
All in all, Spring autowiring has one redeeming quality: candidates are only chosen from the context, meaning instances outside the context cannot wreak havoc our nicely crafted application.
CDI developers should have an hint where I’m heading. Since in CDI
every class on the classpath is candidate for autowiring, this means
that adding a new JAR on the application’s classpath can disrupt CDI and
prevent the application from launching. In this light, only autowiring
by name should be used for CDI… and then, only by those courageous to
take the risk 
From http://blog.frankel.ch/cdi-worse-than-spring-for-autowiring
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
Karl Peterbauer replied on Wed, 2012/02/08 - 2:56am
I don't think that the issues you mentioned are significant problems, since you can use appropriate CDI qualifiers, defaults and alternatives for avoiding ambiguities.
Further more, ambiguities are treated as deployment problem and detected early. Yes, adding a JAR to the classpath might havoc the app, but the same can happen when you change a single line of your carefully crafted Spring XML, which is done more frequently during development.
André Pankraz replied on Wed, 2012/02/08 - 3:53am
in your next article you could reuse parts of the article as argumentation against automatic garbage collection ;)
CDI with type matching works for us...and for many others.
spring with explicit wiring in large projects...that must be fun.
Geoffrey De Smet replied on Wed, 2012/02/08 - 6:43am
Autowiring in CDI works well. If multiple candidates are found, it fails-fast with an "ambigous dependency" exception (compare to this Spring which just takes the first bean with that id in the context even without autowiring).
In the cases where's your wiring beans you haven't defined yourself (and your fear applies), Qaulifiers are used.
The point is that CDI is much stricter then Spring:
- Compile time type checking (even for qualifiers, scopes, lazy beans and prototype beans)
- Fail-fast on ambigous dependency injection
Try CDI yourself, and see if you still feel that way.
Marek Dec replied on Wed, 2012/02/08 - 7:48am
I can see a small advantage of autowiring over explicit wiring, though. When using an annotation based configuration the granularity of your metadata is much finer. The metadata lives very close to the entities it describes (however one can argue if the java way is correct). Managing a huge centralized configuration at application level seems to be a contraintuitive choice.
I think a good analogy here is a book with explanations of the difficult terms in the footer of the current page vs a book that explains all the difficult terms on the first or last page.
What regards the CDI vs Spring autowiring, it is not exactly every class on the classpath that is a candidate for injection. In CDI only classes from jars that are marked as containers of CDI beans will be scanned for candidates (they must have at least an empty beans.xml file in the META-INF directory to be considered bean archives, http://relation.to/Bloggers/WhyIsBeansxmlRequiredInCDI). So, again CDI firmly defines how the autowiring is done. The notion of the 'bean archives' makes perfect sense too - you want to add a bean archive only if you are going to make use of the beans defined there. Spring autowiring approaches the classpath scanning differently, once again, using a configuration parameter defined at the application level. It is definitely easier to filter the beans you want to use during the deployment in Spring. The question is if you should be filtering beans and effectively overriding the class/package level metadata with the application level metadata (shouldn't the class level metadata override the app level metadata?). Personally I don't think the is one strong answer to this question.
I often do find it easier, though, to visualize the CDI metamodel, thanks to the simplicity that comes by default.
Catalin Mihalache replied on Thu, 2012/02/09 - 11:34am
in response to: andrePankraz
I use Spring JavaConfig all the time - no XML, no auto-wiring, 100% control, 100% decoupled beans.
But, in the same time, CDI is a standard JEE technology. However, I'm not happy with autowiring that exists in EJB 3.x and CDI - in Spring terms, it's already old (yeah, is working, of course; EJB 2.1 was working, also)
Karl Peterbauer replied on Fri, 2012/02/10 - 4:20am
in response to: catam1976