Q&A with Norman Richards: Contexts And Dependency Injection in Java EE

This week's refcard from DZone covers Contexts and Dependency Injection, as included in the JavaEE 6 Platform. The card gives a solid introduction to using Weld, the reference implementation for CDI. I met the author, Norman Richards, to find out more about the topic.

DZone: Could you introduce yourself and your experience in software development and JavaEE?

Norman: I've been in the software industry for nearly 20 years, and I've spent most of that time working on middleware and server side technologies.  I've spent the last 5 years working at Red Hat and JBoss, where I was a member of the Seam development team.  I'm currently working at Socialware developing social middleware solutions while remaining an independent contributor to both Seam and Weld.

DZone: What is CDI and what problem is CDI trying to solve?

Norman: CDI is the contexts and dependency injection standard.  It provides a core set of component management and injection services to the EE platform.  The goal of CDI is not to create a new set of a technologies for developers to learn, but to bring existing technologies together in a way that makes applications simpler.  Simplicity is really the most important thing that Java developers need to keep in mind when evaluating language changes, libraries, programming frameworks, etc...  Generally speaking, as Java developers we already have all the tools needed to tackle any development task.  The issue is no longer whether the technology is sufficient for our tasks, the issue is truly how easy is it to implement a task in a way that is both clear and correct.  That is the fundamental guiding principle in the design of CDI.

DZone: Just in case, could you give an explanation of Dependency Injection in simple terms?

Norman: Dependency injection is a mechanism to achieve a simplicity of code and a simplicity of architecture by removing the need for the application to perform component/service lookup and management.  Instead of having to worry about how a component interacts with its environment, a component can simply perform its tasks in a clear and natural way and assume that the environment connects the dots.  When you have a piece of code where there is more code interacting with the environment than performing application-specific tasks, something is wrong that dependency injection can improve.

DZone: So what is Context and Dependency Injections all about in JavaEE?

Norman: CDI is the heart of the continued simplification of the EE platform.  CDI levels the playing field among EE component types.  Whether you are writing a full EE component like an EJB or a Servlet or you are using plain Java objects, everything you write now integrates with everything else in the same way and can make full use of the annotation-driven, type-safe dependency injection system.  But CDI goes a bit deeper than that.

CDI actually goes a step further than just dependency injection though.  CDI provides a declarative way to manage the scope, state and life-cycle of components bound to contexts.  This is really important on two levels.  The first is that many dependency injection mechanisms only understand the easy things: stateless components, singletons and dependent objects.  Things get more complex when you are talking about components that live in the HTTP session or that are conversational.  CDI understands the context of components and can manage them in an intelligent manner across their entire lifespan.

Finally, one of the largest contributions of CDI is the service provider interface. (SPI)   Like most SPIs, it's easy to overlook it.  However, a lot of care has gone into it to provide an extremely robust way to write portable extensions.  Every aspect of CDI, from bean declaration to contexts is extensible.  How extensible?  Well, the SPI was designed with the goal of being able to deliver frameworks like Seam as a portable extension to CDI.  In fact, Seam 3 is being rewritten around the CDI SPI meaning that Seam itself will be usable on any CDI implementation on any Java EE 6 environment.

DZone: Does CDI provide anything beyond dependency injection?

Norman: Definitely.  CDI introduces several new features across all beans.  There are interceptors and decorators.  Interceptors have been a feature of EJBs for some time, but now the interception model spans all CDI types.  Decorators are a type-specific kind of interceptor that really makes traditional interceptor code less-ugly.  CDI also introduces an event model, which allows components to be very decoupled.

DZone: Is CDI only for enterprise and web applications?

Norman: CDI's main use case is enterprise applications, and CDI is at the core of both the web and full EE profiles.  However, CDI actually fully usable in a Java SE world, and there are examples of people using CDI in standalone web applications. 

DZone: What is your top tip from your Refcard?

Norman: I'm very impressed by the Maven archetypes for Weld, the CDI reference implementation.   The Refcard shows how to use maven to get up and going with a new CDI project in just a few minutes.