JSR 299 (Contexts and Dependency Injection for Java) looks pretty good

I remember looking at an early draft of what used to be called the Web Beans JSR and it kinda looked a bit like 'hey lets try standardize Seam'. It didn't strike me as being too relevant or useful to folks typically using Spring/Guice to build their applications.

However I've just had another look at the lastest draft and its now looking pretty good. The rename to Contexts and Dependency Injection for Java certainly helps.

Dependency Injection is such a cross cutting concern throughout the Java ecosystem - its also a very well understood problem space with a small number of popular implementations. We really should have a set of standard annotations for Dependency Injection above the basics in JSR 250 so we really can write framework agnostic code that can work in more than one DI container. So far JSR 299 is the best effort I've seen to try come up with a standard.

Ironcially the annotations used in JSR 299 are almost exactly the same as those used in Guice 2 (@Produces/@Provides, @Named, @BindingAnnotation/@BindingType etc). Also Spring has started adding more and more annotation based dependency injection support of late; so the various approaches are kinda unifying a little.

So with a bit of effort it should be pretty easy to implement the dependency injection parts of JSR 299 in both Guice and Spring; so then we'd have a real, useful, dependency injection standard working across all the main DI frameworks.

I wonder if the Spring & Guice folks will put petty politics aside and really get behind JSR 299 for the good of the Java ecosystem?

Using Guice as a JNDI provider

In many ways a Dependency Injection framework is a replacement for looking things up in a registry like JNDI; but sometimes having some kind of registry or JNDI provider can be useful such as if you want to work with JSR250/EJB3 or some legacy code which expects JNDI to be used - or you want to use JNDI as a kinda loosely coupled registry between completely different modules of your system.

I've hacked up a simple JNDI provider which just uses Guice to create all the objects; so you stick to pure Java code for writing your Guice Modules to depenency inject your objects together then have a little properties file to enable/disable/tweak things.

When looking at Guice through spring-tinted glasses the most glaring difference (apart from the lack of XML) tends to be the absence of the ApplicationContext and a registry where you can look things up by name. This JNDI provider provides a more standard alternative to the ApplicationContext, as JNDI is in the JDK and it kinda gives you that crutch to lean on until you figure out the guicier way of doing your dependency injection :). 

One neat thing is it combines JNDI naming with the @Named injection points in Guice and allows @Resource from JSR250/EJB3 all configured via the same jndi.properties file 

Adding support for @PostConstruct, @PreDestroy and @Resource to Guice

I do like guice as a Dependency Injection engine; I think it has a lot of promise; particularly if 2.0 is released soon :)

I still struggle sometimes, coming from a spring framework mindset, figuring out how to do some stuff. Though I love the @Provides support in trunk of Guice. Here's hoping 2.0 is out soon! :)

I've experimented recently adding support for ConstructorInterceptors into guice so you can add custom lifecycles like @PostContruct from JSR250/EJB3 or Spring's InitializingBean etc. 

I've also created a patch to support closing of singletons such as via @PreDestroy or spring's DisposableBean.

Slightly more wacky is a patch adding support for custom injection point annotations which allows you to easily support things like 

• @Resource from JSR 250/EJB3
• @PersistenceContext from JPA
  
• the various JAX-RS annotations like @Context, @PathParam etc
• WebBeans @In
• Spring's @Autowire
• Apache Camel's injection annotations like @EndpointInject or @Produce

Feedback greatly appreciated!