[jsr-314-open] getting behind CDI

[Jeremy Grelle]

On Dec 22, 2009, at 10:08 PM, Dan Allen wrote:

> I'm going to disappoint you slightly because I don't think this list  
> is the appropriate place to compare Spring 3.0 and CDI. I would like  
> to avoid an unbounded thread, which these things inevitably turn  
> into. My best advice for you is to simply evaluate the two reference  
> guides and post your conclusions.

Agreed.  And thanks, Dan, I suspect you've just saved me a whole lot  
of typing.  We are both passionate about our chosen frameworks and I  
don't really think either of us is in the position to give a truly  
unbiased comparison.  The fact is, they can both help you get your job  
done, but they take fundamentally different angles of attack.

> So if something isn't working out for you, it's certainly possible  
> that an extension will be able to fill in the void. I'd go so far as  
> to say that a framework like Spring could leverage the extension SPI  
> heavily to integrate itself into Java EE if the developer was  
> looking for that type of bridge. (Experience will tell us if that is  
> true). There are certainly places in Spring today that it has to go  
> searching for information that now the CDI extension SPI could  
> provide for it for free.

That is a possibility (at least in theory...the devil is in the  
details), and a path we would consider if we had sufficient demand  
from the Spring community.  To be perfectly honest, it would surprise  
me at this point if we did get that level of demand, but I'm always  
willing to be surprised.

> That's my brief sketch of CDI. The advantage that Spring has is that  
> it's incredibly well-known and, well, it's at version 3.0. It  
> wouldn't really be a balanced equation to compare Spring with CDI  
> anyway, since Spring is so much more than just a bean container.

Indeed, and it is my duty to continually remind people of that fact  
since I mainly work on the "more". ;)  One cannot overstate the  
leverage we get in Spring's higher-level modules, including the main  
framework modules as well as all of the surrounding projects like  
Spring Security, Spring Web Flow + Faces, Spring Integration, Grails,  
etc. by being able to depend on a very stable, well-documented, yet  
always improving core that isn't constrained by the timelines of EE  
spec releases.  This allows us to bring a continuously expanding set  
of functionality with an extremely consistent programming model to our  
users across a rather diverse range of problem sets, and that's  
obviously something that we've been very successful with.  (For anyone  
who may still be wondering why we've chosen not to change the core  
behavior of Spring in the subtle, yet fundamentally different ways  
that would be required to implement CDI, I hope this bigger picture  
helps make our reasoning a little more clear.)  CDI has the potential  
to bring similar benefits on its own to the "native Java EE" crowd,  
and for such folks who choose not to use Spring for whatever reason  
(as is their right), I'm sure the advance is quite welcome.   
Meanwhile, we're happy to continue giving Spring users what they've  
come to expect, and let new users to the Java platform make the choice  
that best suits their needs.  And that's about the extent of  
"comparison" you will get out of me for the moment...  :)

> Besides, it's the holiday and we don't want to create a long thread  
> to distract folks from their presents (and family).

+10.  Happy holidays, everyone!

Cheers,

Jeremy