A quick caveat before I begin — I’m playing devils advocate here, so I have no idea if I believe any of the gibberish that I’m about to write 🙂
On one hand, I think it’s Mostly Harmless… CDI/JSR-299 is obviously the default implementation of the spec, and perhaps having a very small portion of the DI capability abstracted so that we have the choice to use another framework if we want isn’t necessarily a bad thing (even if standardizing injection targets isn’t exactly ground breaking value) — after all, if it weren’t for those ‘outside’ framework writers, we might not have gotten EJB 3, and all the improvements that came along with Java EE 5… perhaps JSR 330 is a way to bring those folks inside of the Java EE fold, so it’s not another three years before the standards catch up with the private innovation
On the other hand, is it at all likely that an application would be able to just replace the DI capability of CDI with, say, Spring or Guice, but still use the contexts, interceptors, extensions, etc? After all, Dependency Injection is actually a pretty small part of what the CDI spec provides… Perhaps, if one were to write a CDI Portable Extension that basically vetos all bean discovery, and instead uses one of the other libraries to do the injection, but that seems like a stretch to me…
What seems more likely is that another implementation would simply not use CDI, which can easily be done by not providing a beans.xml file, and using some other mechanism, like the Spring WebApplicationContext — in that case, is there value in what the JSR-330 spec provides? Has the addition of this spec, which provides little value in-and-of itself incorporated too much confusion?
My original instinct was that it’s a good addition to the Java EE fold, but I’ve heard a few voices of opposition (including from those who don’t have a big stake in the outcome)… now I think, perhaps, that I could take it or leave it — I haven’t been convinced that it’s destructive, but I’m also not convinced that it’s worth it 🙂
What do y’all think?