This morning, Google and SpringSource submitted an updated version of the aforementioned @Inject proposal to the JCP. In response to popular demand, we expanded the proposal's scope to include a low-level build-time and run-time configuration API. You might think of the new API as a type-safe analogue to JNDI and @Resource. Having a central integration point for DI configuration means you can use multiple configuration approaches in a single application without suffering from the-chicken-or-the-egg problem; anyone who has tried to use more than one DI framework in the same application knows that deciding which framework to initialize first can be problematic to say the least.

Our goals are to enable portable applications and to spark further innovation in the DI configuration space. By making it easier to use multiple configuration approaches with the same tools and in the same application, we lower the barriers to entry and adoption for new approaches.

We've added the following paragraphs to the JSR proposal's introduction:

A programmer configures a dependency injector so it knows what to inject. Different configuration approaches make sense in different contexts. One approach is to search the classpath for dependency implementations, avoiding the need for the programmer to write explicit code. This approach could be useful in quick-and-dirty prototypes. A programmer working on a large, long-lived application might prefer a more explicit, compartmentalized approach. For example, the programmer could write XML that tells the injector to inject an EJB client proxy named "NetworkTimeSource" when a class needs a TimeSource:

  <binding type="TimeSource" ejb="NetworkTimeSource"/>

It often makes sense to use more than one configuration mechanism in the the same application. For example, a quick and dirty prototype might grow into a real application, and the programmer could incrementally migrate to a more maintainable configuration. As another example, a program might configure some resources explicitly, while others are configured automatically based on an external XML file or database.

This JSR will standardize a low-level kernel API that can be used directly by a user or as an integration point for higher level configuration approaches. This approach enables portable Java applications without quashing innovation in dependency injector configuration.

We've rewritten the scope:

This JSR will standardize:

1. A set of annotations for use on injectable classes
2. A typesafe, user-friendly injector configuration API that provides an integration point for higher level dependency injection configuration approaches

And we've adjusted the time line and other parameters accordingly. Check out the full proposal.

What will the new API look like? That's for the expert group to decide, and they'll do so in an open and inclusive manner. In addition to Guice and Spring, this proposal already has support from the PicoContainer, Plexus and Tapestry IoC teams, not to mention prominent users like Tim Peierls and James Strachan, and well known API designers like Doug Lea and Josh Bloch. We'll have no shortage of expertise when it comes time to assemble the group.

Guice 2 already provides a great foundation for extensions and tools. The Guice team is excited to start with a clean slate and apply the lessons we've learned over the past few years. This time around, we'll be able to work with the platform instead of around it. As a member of the JSR-294 expert group, I'm eager to align our dependency injection efforts with the module support coming in Java 7. JSR-294 modules will enable sharing types, and this proposed JSR will build on that foundation and enable sharing instances.