I found the following features particularly interesting, which will probably be taken aboard by Spring in the future:
- Provider: you can inject the provider rather than the dependency. That allows the class to instantiate multiple copies of the class, instantiate the copies lazily or conditionally. Also, if you have dependencies that have different scope (like having a request dependency in a session object), you can handle this case much better.
- Development stages: this seems to be something for the next version, but it is pretty cool. You can specify beans to be loaded according to the stage (devel/prod), not loading unnecessary beans while you are developing.
- Constructor listener: another feature for the next version. In short, to be able to intercept the construction of any of the dependencies to be injected.
I guess it will be hard to come up with a framework to beat Spring, but it seems that Guice and Google products have much better political acceptance and may have better chances of making its dependency injections officially supported in the JDK and sponsored by the JCP.
Update: I found an article that supports my comment above about Web Beans + Guice where one of the readers commented:
There's been a lot of talk over the past few years that perhaps Interface 21 should push to formally make the Spring Framework a part of the JEE specs -- it seemed like it might be possible with Rod Johnson officially declaring his support for JEE 6... well it looks like "Crazy" Bob Lee and the team behind Guice may have found a back door to get themselves into the party first -- according to a new series of articles about the upcoming Web Beans, the new spec is actually influenced by a combination of Seam and Guice ... I find these articles interesting in that Google has apparently taken the JBoss approach to supporting the JCP -- that is, create an independent product to fill a whole in the JEE specs, and then use the JCP to make that product into a spec itself (take a look at the JPA for a previous example)...