What Is The Relation Between JSR-299 and JSR-330 In Java EE 6? Do We Need Two DI APIs?

"It is amusing to see that the built-in qualifier @Named is not recommended and should be used only for integration with legacy code"

 I don't think you're comprehening this very well or your wording isn't making sense.  The spec says "The use of @Named as an injection point qualifier is not recommended".  However, you very much need @Named to declare the bean EL name.  There is nothing amusing about that.

Ah, the market leaders in Dependency Injections -- Spring via Rod Johnson and Guice via Bob Lee -- simply don't understand the true power of CDI, and therefore they built something that was dumbed down. The new comer to DI -- Gavin King through Seam -- understands the needs of a DI environment much better... Thanks for the clarification!

That's IT dude... newer = better. Spring was once the king of DI, but now we have something better.

Both the Spring and Guice camps have expressed strong reservations about the details of CDI. Bob Lee was on JSR 299 and left due to incompatible technical vision. I have yet to see convincing evidence that CDI is indeed better than the commonly used alternatives.

Just because there has been innovation in other fields, doesn't mean that CDI is THE way to go for DI. I'd love to see a fair comparison between CDI's approach and the alternatives that would show me the pitfalls for complex enterprise software. I'd rather stick with the tried and true de facto standard, for now, before plunging into a so called "standard" that recreates complex, mostly unproven functionality from scratch.

Both the Spring and Guice camps have expressed strong reservations about the details of CDI.

 

Precisely where have the Spring folks expressed and explained these "strong reservations about the details"? Isn't it interesting that they havn't actually let the rest of us know what their detailed reservations are? And if they had such detailed reservations, why didn't they join the 299 EG when invited, or at least send technical feedback to the EG, or explain their reservations in their JCP non-votes? Where can we all go to discover what these "detailed issues" were? In fact, if they had such detailed reservations, why did Spring not vote on the CDI (or EE6) JSRs?

As it happens, we do know what Bob Lee's "detailed issues" were:

1. That CDI uses proxies for normal-scoped beans.

2. That CDI scans bean deployment archives to automatically discover beans that can be injected.

Now, interestingly, recent versions of Spring have adopted both these ideas. So Bob's "detailed issues" are also, presumably, reasons to not use Spring? Of course, in the opinion of others, both these items are useful features of CDI, that make CDI easier to use than Guice. Oh, and if these issues are such problems, why did Google vote yes on the CDI JSR?

Oh, and by the way:

1. I'm pretty sure that Seam has a bigger user base than Guice, making it one of the market leaders in dependency injection. So discounting my view as a "newcomer" is perhaps unfair, don't you think?

2. Both Bob Lee and myself have publically expressed very strong reservations about Spring. And both myself and, I'm certain, the Spring folks, have reservations about Guice. Does that mean that you shouldn't use Spring? Or Guice? Or does it mean that you should actually pay attention to more disinterested observers than to authors of competing software, or try things out for yourself?

What's the relationship between SEAM 2 and CDI? Does that resemble Hibernate 2 and JPA 1? I noticed Hibernate 3.2 is only trivially not backwards compatible with Hibernate 2. To what extent is SEAM 3 backwards compatible with SEAM 2?

See here:

http://seamframework.org/Weld/JSR299AndWeldOverview#H-HowDoesSeamRelateToWeldJSR299

Well for me it's the everyday 'involved' Java developer, there's ten's of thousands of them (if not more) who simply try out several options and take the best of breed/fit for purpose solution for their needs. They _don't care_ about the politics although it does provide some entertainment on a Monday morning reading various threads either here or on TSS ;) It's a good point though Reza, there does need to be some recognized expert(s) that are neutral that can weigh in on these debates/comparisons. Although my unscientific estimate of ten's of thousands of developers that have the will and the time to try things out, there are probably hundred's of thousands of developers who would benefit greatly from clear cut neutral comparisons. I suspect such experts will be difficult to find as they'd need both the expertise in both camps as well as the time to experiment and write such results up. Not easy to do whilst performing a paid job I suspect :)

Well for me it's the everyday 'involved' Java developer, there's ten's of thousands of them (if not more) who simply try out several options and take the best of breed/fit for purpose solution for their needs.

This is exactly the right approach. Try things out for yourself. Pick the solution that works best for you. I am very, very confident that a very large % of the people who actually try out Java EE 6 and CDI will eventually decide to go down that path.

Reza,

A while back you wrote the first part of a series of articles about JSR-299/CDI: Dependency Injection in Java EE 6

This article was really well written. Are there still more parts coming? I hope so :)

Call me old fashioned but I think Spring had it right in the first instance with xml IoC addressing configuration and dependency concerns. The simple annotations in JSR 330 are easy to understand but I can live without them and I find xml based application contexts a great in documenting a blue print of the runtime of an application.

JSR 299 however , I cannot see much straight forward documentation about it. For example This Reads like a binary file.

Personally I dont care of EJB or JSF, why should I ? I just want to relate one bean to another and inject propertys. Maybe JSR 299 is harking back to the good old days of EJB 2 and just inventing and perscribing ideas that in practice people have little need for.

Ha ha, Seam under another name, CDI :-)