There's been some interesting feedback from JSR299 folks on the new @Inject proposal. (Though there is a bit of argument for argument sake in there :).
I can understand 299 folks wanting there to be just one spec that talks about IoC. However IoC is a large complex area that is still undergoing quite a bit of innovation (e.g. see the changes in Guice 2 and the JavaConfig which is part of Spring 3).
For me the great thing about the new @Inject JSR is that its small, simple and focusses on the common well understood part of IoC (the annotations you add to your objects so that popular IoC containers can inject your objects). This is the thing I most want - a standard set of annotations I can use everywhere in objects - then consumers of those objects can choose whatever IoC container they wish to wire things together be it Spring or Guice or a JSR 299 provider or whatever. The actual wiring code (in Java, XML or some other script/language) tends to be kinda small stuff relative to the tons of Java code for the objects themselves. Given the large variety and constant innovation in the wiring side of things, its probably a bad time to try lock that part down as I don't think there's consensus on how that part should look (though Guice 2 and Spring JavaConfig seem to get closer all the time).
299 however standardizes lots of things which only seem to be done in Seam; I don't see Spring, Guice or Pico implementing 299 any time soon as its a bit too big - however all IoC containers should be able to implement @Inject pretty easily; most IoC containers have already got something like @Inject in them today.
So as a practical kinda guy at heart, the best way forward IMHO to be able to write IoC container agnostic objects that can then be injected by Spring, Guice, Pico, Tapestry or indeed a 299 provider seems to be the @Inject JSR.
This doesn't mean 299 isn't useful; there's some interesting stuff in there particularly relating to eventing and JEE integration to IoC; but I see getting @Inject done and adopted by Spring, Guice & Pico (and hopefully the JSR 299 RI too!) to be most important for IoC in the Java ecosystem as a whole.
