The dependency injection controversy, or how two groups can do the same thing differently

Last week SpringSource and Google, specifically the Guice framework developers, made a joint announcement introducing a proposal for annotations to manage dependency injection (DI). What makes this interesting is that Java EE already has a fairly advanced, if not finished, specification under JSR 299, formerly called Web Beans. I don’t suspect SpringSource or Google of being unaware that Web Beans covers almost the same ground. But the old saying holds that two people doing the same thing can produce different results.

A response from Gavin King, the lead for JSR 299, came quickly. He faults their proposal for being too superficial and leaving out many aspects of DI, such as management that depends on the deployment, and he’s right. The question is whether SpringSource and Guice have enough interest to take on that kind of specification. The latest fairly skeptical comments by people at SpringSource about Java EE 6 and its profiles, made at the SpringOne conference, suggest they don’t.

Most of the things Gavin King describes are available out of the box in Spring at least. Maybe the people around Rod Johnson just think JSR 299 will go the way of other fairly ambitious Java EE specifications. Perhaps the problem is that it wasn’t written as a strictly DI-focused specification from the start, so its portability to standard Java is quite limited. It could end up as an experiment on developers that only becomes usable in its third version, although personally I don’t think the specification is bad at all. Another possibility is that JSR 299 won’t make it into Java EE in the end, something the people at SpringSource may know.

Whatever the reason, it undeniably reflects badly on the entire Java specification process. Again, Rod Johnson and company have never spared it their criticism. In the end it looks like everyone is pursuing their own interests and nobody really cares about wider agreement.