Rob Williams is a probabilistic Lean coder of Java and Objective-C. Rob is a DZone MVB and is not an employee of DZone and has posted 170 posts at DZone. You can read more from them at their website. View Full User Profile

First Quick Look at CDI (of JEE6)

09.03.2010
| 7331 views |
  • submit to reddit

The good news is that you can have a parameterized constructor (one). The docs (at least the Weld docs) tell us that this allows us to have immutable objects. A builder (a la Bloch‘s from EJ2) would have been better, but this is a great relief from the stupidities of default constructors on every object.

As I push farther into this document, though, I‘m kind of overcome by the thought that Enterprise dev is turning dependency injection into its version of string theory. The purported advantages of DI are that you make explicit the wiring up of components. But DI came in on the XML boom where we had cabinets of interconnects that were nameable and traceable. Ok, argument makes sense: pull the random uses of new out of the code. Also, wire together compound components into bigger units (something language does not deal with exceptionally well because there is no concept of a component in any languages that are out there). So doing bean definitions in XML that had subcomponent wirings explicitly laid out made sense. Problem was, XML became its own nightmare and people decided annotations made more sense. So it‘s ‘ok, let‘s go back into the code,‘ begging the question ‘um, how are we better off than we were when we used to do this in the code?‘

The answer is that we have a container doing work for us, assembling components and then managing their scope.

One thing is for sure, and this is generally a good test of whether we are off in the weeds: if we were starting from scratch, JEE6 and CDI would not be what we would produce. That I‘m sure of. It‘s got all the hallmarks of rutted, grooved warps and whip marks. Of course, because the generals are always fighting the last war, but also because each act of creation is simultaneously the putting to death of some prior genus and the birthing of some supposedly superior species, this is what the various powers have come up with. (Further proof that committees drafted from a few of the cognoscenti does not mean you get some magical incantation involving colored smoke and a visitation. As a matter of fact, apparently the road to CDI was insanely contentious and nasty. Read a Guice Bob rant about what a nightmare it was to work with Gavin King.)

The theater of that in JEE6 is not quite as successful as it was in JEE5. Then, we were getting JPA, which made so much bloody sense, the rest of the train was taken on spec. DI, now that it has gotten its moment in the sun, is starting to look more like a rash than a solution to any immediate problems (other than the DI problems of the prior round).

I was reading a blog on here the other day where some guy was flummoxed because he‘d had an app where he had 10 different versions of the same interface dutifully laid out in his XML file and did not know how to do the same with annotations. I suppressed the urge to suggest starting over. Might be a good piece of advice for the spec guys too. I do believe that CDI is better than continuing on with Spring (now a commercial force) with no standards coverage.

 

From http://www.jroller.com/robwilliams/entry/first_quick_look_at_cdi

Published at DZone with permission of Rob Williams, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Reza Rahman replied on Fri, 2010/09/03 - 10:02am

Rob,

Thanks for the CDI coverage. It wasn't entirely clear to me if you had an alternative DI model in mind other than CDI, Spring or Guice? If you do, what is it? Examples would be great but even a relatively abstract idea is fine.

I look forward to hearing specific areas of suggested improvement as you dig deeper into CDI (we are now just gearing up for Java EE 7 ourselves). I'm no "general" but I'm certainly not too engaged in the "last war" as to not keep my eyes and ears open to valid, constructive suggestions from intelligent people that know what they are talking about...

Cheers,

Reza

Fab Mars replied on Fri, 2010/09/03 - 9:59pm

It's not even a bloody coverage. And I doubt the author knows what he's talking about.
There are many statements in this article that are rhetoretical, biaised, or just totally wrong.
Same thing as with the dumb JSF rant produced a while ago.

Bob, you should document yourself on how CDI was elaborated, based on which experience, and in which context. The problems were much smaller than what you described. IMO an enterprise facing tough competition succeeds better with new ideas out of a smart brain, than out of silly consensus. Anyway, the root cause of the few hot moments were mainly political (up to the JSR330).

You should also document yourself on EE5/EE6. Especially EE6 now and prior to posting. There's really a lot of new, brillant and useful technology there (ok ok JPA2 is maybe overengineered). But come on, what I'm reading here is ridiculous. If I understand you well, CDI is the lesser of 2 evils, partly because one of its galore features gives an "official" solution to an old problem?  CDI is not only about DI fyi. Check the tutorials for God's sake!

Finally, what if one said your brand new car full of new technologies is not addressing immediate problems just cause it has power locked doors? What if you unplugged all the fuses in that (EE6) car, attempted to dirve for 5 minutes, and then claimed on a public website that this version is less successful than the previous one?

Questions:
- what do you propose instead of CDI?
- what are today's immediate problems?

Bozhidar Bozhanov replied on Sun, 2010/09/05 - 4:15pm

Reread this post and ask yourself whether it's not just a rant without any sign of concreteness.

In this thread I've made some (I hope) less biased points about CDI

 

Btw, Spring commercial? VMWare is, but not the sprign framework.

 

CDI is based on Seam, Guice and Spring. (less on spring, alas). And it looks good when you get into depth - it is a mature DI framework. Whether it's better than spring or guice - time will tell.

Rob Williams replied on Sun, 2010/09/05 - 6:22pm

@Reza: I started using Spring a LONG time ago, like 7 years. I am not opposed to DI, just saying that now that we have a standards-based version (which I do believe is better than not having one), to me, it seems that the amount of fuel, and now the amount of complexity is out of proportion with the problem that is solved by DI. Furthermore, I see a LOT of people misusing it. The example at the end of making 10 variants of a bean is typical.

I would contend that DI is a very shallow technology in actual adoption, meaning that 90% of people are using a very small number of features, most of them just using it to get their hands on the entity manager.

Go do a little iOS dev with CoreData. It's pretty easy to just create objects and persist them.

@Fab Mars: You are a clown. I am taking a first look at JEE6, having used JEE all the way back to the bloody first betas. I am not saying CDI is useless or that there should be some other implementation. You would maybe not get so wound up about posts like this if you understood them.

Reza Rahman replied on Mon, 2010/09/06 - 12:42pm

Rob,

Understood and I agree. These are some of the issues I am trying to deal with myself via best practices for using Java EE 6. Indeed, I would say it is not a cardinal sin to not use CDI at all in favor of the more vanilla Java EE 6 APIs (JPA 2, JSF 2, EJB 3.1) or simply focus on using the CDI sub-set defined by JSR 330...

Cheers,

Reza

King Sam replied on Fri, 2012/02/24 - 9:48am

I'm not sure what you're trying to say exactly, but it seems you just don't like CDI. Well, I've got news for you: other people do! :P

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.