Guice 2.0 presentation: no more reasons not to like dependency injection

Dependency Injection is one of the most controversial improvements made in software development over the last few years. Dependency Injection really helps modularization of code, which in turn, among other things, greatly improves the ability to unit test code. On the other hand, dependency injection either requires tons of hand-written factories or a framework. DI frameworks may have their issues of their own, like doing a lot in complicated XML, a large footprint, too much “productivity improving” added voodoo magic, not being to inject everywhere, etc. Over the years, DI frameworks have competed fiercely with new ideas and new concepts, and though DI frameworks have been useful from the beginning, they are really a lot more powerful and easy to use nowadays.

A Dependency Injection framework will be part of the Java EE 6 spec. To be honest, I have mixed feelings about this. On the one hand, it’s great to finally see these concepts embraced the spec, hopefully, it will end the silly battles of “it’s not a Java EE spec idea, so it cannot be used”. On the other hand, there are some serious drawbacks. First of all, the DI specified in Java EE 6 does not work outside the container as by the specs. You will need DI outside of container a lot: when writing stand-alone applications, when wanting to do out-of-container integration tests, simple standalone conversion code, etc. Of course, nothing prevents DI frameworks from adding custom API and support for this, but this defeats the purpose of having a standard.

Also, DI is a much more evolving topic than for other infrastructure-oriented API. HTTP, JTA, JMS, JMX, are infrastructure-oriented solution APIs, and as such are most likely limited to evolve based on the underlying technology, while DI sits on a much different level. This spec will hopefully be final soon, but it will probably take at least a few years for vendors and customers to adopt to this standard. In two years, DI will probably already be evolved by then, making the current spec solution suboptimal by comparison, and the DI part will not be as popular as one might expect now. On top of that, a competing standard (JSR-330) is working on a
standardized interface for DI frameworks that is different from the one
in the EE6 spec. This means the Java EE DI spec will have competition even from another JSR!

Meanwhile, Google released version 2.0 of their Guice DI framework. This presentation gives a great introduction on why you need Dependency Injection in general, and what Guice is all about. No large-mouthed marketing, no mud-slinging, a very technical and honest talk. I really like Guice 2.0, it’s really easy, powerful, fast, small footprint, OSGi enabled, works everywhere and tries to solve one and only one problem. If you like DI, be sure to watch the presentation, if you hate DI, watch it too. No need to wait for a big spec change and a server upgrade, just start using today’s great ideas today.

Update: it appears the Java EE 6 spec will adopt to JSR 330, this solves several of the problems I mentioned. Guice will probably adopt JSR 330 as well, as the Guice architect Bob Lee is on the spec team.