The Good and Bad of CDI
A little background
CDI has had a major influence in the Java community. It's inclusion into JEE6 has greatly improved the way of working with JEE in general, this itself caused a major leap in adoption of JEE. So far so, that it's being applied indiscriminately, something I'm not much of a fan of. For most of the web applications being built, CDI is a great tool to accelerate implementation.Then to what CDI does, CDI stands for Contexts and Dependency Injection. The latter is for the most part what it does very well, Dependency Injection. The former, Contexts, is what I'm sceptical about. The thing that makes CDI so very powerful (and at the same time, weak), is the fact that it puts a great big layer between beans, this allows beans to be initialized lazily or even in different scopes.
Another thing CDI does well, and poorly, comes from the fact that apparently, we're afraid of configuration these days. We just want everything to work now, without having to do anything for it. CDI does this by just scanning through all your packages to decide what is a bean, and what isn't.
The Good
Well, as mentioned, there's a lot that CDI does well. Dependency Injection it does great, making everything work 'now' is great too. As is handling all this silly scope stuff we don't want to be bothered with.There is one thing that really sets CDI apart from other DI frameworks (like Spring or Guice), one that makes CDI extremely powerful, is events. The ability to (ad-hoc) define observers and emitters is extremely useful, especially the easy of use.
The Bad
The (my) problem with CDI comes from the big fat layer of byte code generated goo that it sticks in between everything. Together with the fact that CDI seems to think everything is a bean, aggravates this big goo.Since Java some neat methods to mitigate problems with Liskovs substitution problem, I consider code quality rules such as, everything is final or abstract, to be very important. CDI breaks this, in a fundamental fashion, since everything is a bean, interfaces and their role in separating contract and implementation, don't seem to exist. This makes the use of CDI bad in many cases.
The CDI idea of, everything is a bean, means that it's forced to scan everything when starting an application. This can cause a perfectly reasonably small application start up in 5 minutes instead of 15 seconds. I would like nothing more than to say these number are exaggerated, except, I can speak from experience that they are not.