Spring is the most advanced implementation of the "post EJB" vision, and it's hard to see that changing in the near future. The Spring team is advancing at a rapid pace. (The fact that Spring is a moving target has made the writing of this book more of a challenge.) Crucially, Spring's design is highly adaptable: It is possible to add many new features without modifying the core container because of the hooks the container offers.
Spring's momentum continues to grow, so you can rest safe in the knowledge that your project's investment in Spring is safe for the foreseeable future.
Despite the rapid pace of Spring's evolution, you can rely on backward compatibility. Because of Spring's design, and the use of IoC and AOP, your code is not coupled tightly to the Spring internals — indeed, it's often not coupled to Spring APIs at all. Thus, as Spring evolves, your applications need not be broken.
EJB 3.0 is being heavily hyped by Sun and — especially — some application server vendors. (Given the vested interests in keeping EJB alive, at least as a name, this is hardly surprising.) But it's unclear what benefit it will offer.
The EJB 3.0 specification (still in early draft at the time of this writing) seems set to offer a small subset of Spring's Dependency Injection capabilities. This offering may look compelling to those who have never used a Dependency Injection container. But it is far from innovative.
We believe that the day of the EJB container is coming to a close. The concept of a monolithic container that offers a fixed set of services is clearly dated. It will be replaced by more lightweight containers that are not J2EE-specific or restricted to use on the server side, and which deliver services to POJOs through Dependency Injection and AOP. Spring already offers such a model, in mature, battle-tested form.
It is, however, important to note that Spring will provide support for users who choose to use EJB 3.0, as it has always supported EJB 2.x usage. And Spring of course offers many valuable features not addressed by EJB 3.0, as well as features that EJB 3.0 is also attempting to deliver. But there seems little compelling case for EJB today.
The POJO persistence specification to be released by the JSR-220 Expert Group, distinct from the EJB3.0 specification, is a different matter. We expect that this will become an important API, and Spring will provide full support for it as soon as it is released.
However, as the next few years play out, it's certain that the lightweight container movement has changed the face of J2EE development forever, and that open source projects — particularly, Spring — have played a huge role in defining and popularizing new features. This innovation is likely to continue. As part of the Spring community, we hope that you will help us make Spring better and better. Spring is what it is today partly because of the community spirit of its developers and users — we welcome you to participate in that!