I'm curious about your opinion about the future of EJB's. With Java EE 6 we received a very powerful technology which is a CDI.
Do you think that in the future EJB 3.2 (or even in next versions) the EJB should be modified to such degree that i.e. the transactions support would become easily available not only to the EJB's but also to the CDI managed beans?
Nowadays we've got EJB interceptors and CDI interceptors and decorators. We've got SLSB, SFSB and singleton beans and on the other hand we've got request, session and conversational CDI scoped beans.
It's quite hard for the Java EE newcomers to understand that under the Java EE umbrella we've got so many technologies that somehow overlaps each other responsibilities.
How do you think this situation -- and specification -- will evolve?
And the last question (yeah, I know - it's a cliché!): if, next to you, you would have a Spring developer who is used to the Spring approach, would you try to convince him to switch to or at least take a look at the EJB's 3.1? Do you think that besides the no-vendor-locking argument, EJB's still have something to offer for such developers?
Do you think that it's possible that the Spring and Java EE technologies would become an allies (or maybe they're already are?)
Thanks in advance for your time!
OCP Java SE 6 Programmer, OCM Java SE 6 Developer, OCE Java EE 6 JSPSD, OCE Java EE 6 EJBD, OCE Java EE 6 JPAD, Spring 3.0 Core Professional.
With regards to the future of EJB see: http://www.coderanch.com/t/548607/EJB-JEE/java/EJB-CookBook-next-EJB. Part of this effort should address the "Alignment and integration with the simplifications and enhancements made by related JSRs within the Java EE 7 Platform umbrella (e.g., CDI, JMS, Bean Validation, ...)". Hopefully this will minimize the confusion of some many related approaches offered by EE. It will get better but there will always be the legacy code to deal with.
We should always keep an open mind with regards to new and different technology. That is part of what makes this such as interesting field to be in. EJBs are probably better integrated with other technologies than Spring. Regardless, there are many factors other than technology that goes into the decision making process. I don't see Spring and EJB so much as enemies as simply different approaches to solving a common set of problems.