End of Spring vs EJB wars in sight?
Tonight I watched a video of Rod Johnson doing a presentation on Spring 2.5 at Google. He said that Spring 3.0 will be an EJB 3.1 Lite compatible container so that the Spring Application Platform can get the Java EE 6 Web Profile certification if the expert group chooses to include it in Web Profile. Spring will also be a full featured EJB 3.1 implementation for use in the WebLogic application server. The Java EE 6 expert group has polled the community and it seems that most developers want the larger Web Profile which includes EE 6 technologies intended for the web. I wonder if the expert group has decided which Web Profile proposal to use, and whether or not JSF + Web Beans will be included? In Rod's video he mentioned that the design of Spring 2.5's dependency injection annotations are based on lessons learned from EJB 3.0's @Resource and Google's Guice. I am interested in knowing his thoughts on Web Beans annotations which is also third generation, and if Spring will become an implementation of it.
Anyway, I think this news is a BIG DEAL for EJB, as much as JPA was. If Java EE 6 Web Profile includes EJB 3.1 Lite and Spring is an EJB 3.1 container without requiring addons, then developers might choose to use the JSR standard annotations and XML over implementation specific ones for all of their work. This will be even more desirable if Java EE 6 Web Profile includes Web Beans and Spring has built-in support for that too. In the video Rod encouraged developers to use EJB's @PostConstruct and @PreDestroy annotations because they are standardized and Spring has built-in support for them. This could be the end of Spring vs EJB wars.
Look at what JPA (from EJB 3.0 expert group) did to the industry. Today many developers prefer to code using JPA standardized annotations and XML configuration by default, and only use implementation specific features where JPA is lacking until the next revision of the standard comes out.
Originally posted on ryandelaplante.com
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)