Wednesday, May 20, 2009

It's in the JCP's hands now.

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.


Blogger unibrow said...

Great news! Keep up the good work.

7:58 AM  
Blogger 72 Services Blog said...

Good news!
With the additional possibility to define what exactly has to be injected it's much saver in big environments. And it's closer to my own DI framework simject ;-)

Greetings from Switzerland

8:11 AM  
Anonymous Anonymous said...

It is nice to see Google and Spring working together on this. In many cases you wouldn't see this kind of cooperation from rival open-source projects.

Imagine if the Eclipse and NetBeans folks could work together like this on a common plugin framework.

9:42 AM  
Blogger Shinpei Ohtani said...

Great to see!
This spec is exactly I've been looking for a while.

So mind if I transfer this draft to Japanese so that Geeks in Japan exactly know what's going JSR330?


11:27 PM  
Blogger Shinpei Ohtani said...

Some bad English, I found.
I mean translate to Japanese, not transfer.

11:33 PM  
Blogger Ivan said...

Congratulations! Agree with the cooperation between Google/Spring - proof huge organizations can align together for the good of developers :)

2:13 PM  
Blogger Tim said...

Bob- Congratulations on the Guice 2.0 launch. I wish I could say I had any idea what that means or how it works, but I don't have a clue. But it's always good to see a fried do well.

5:24 PM  
Blogger Ondrej Medek said...

Good work, finally we will have some DI standard.

2:55 AM  

Post a Comment

<< Home