- CDI has the potential, I believe, to provide all of the most commonly used services that the EJB spec provides, and let’s face it, this mean transactions, timers, asynchronous process with MDB’s, and now Singleton Startup beans. It does not mean remoting, instance pooling, and most certainly not any of the old CORBA crap 🙂 — also note that I’m not referring to JPA here at all, now that it has been removed from the EJB spec (as it should be!)
- The CDI spec comes in at 98 pages.
- The EJB 3.1 spec (PFD version), comes in at 618 pages — yikes!
- The CDI spec is far more flexible than the EJB spec, allows for more interesting and transparent customizations, and is built specifically to support extensions.
- CDI’s mechanisms for injection (which it inherits from JSR-330, thanks to Rod and Bob!), is more consistent, inclusive and unified than EJB’s/JEE 5’s.
- CDI’s inclusion of Stereotypes provides an awesome mechanism to create a lightweight framework, without directly exposing any CDI api to the end user.
- CDI’s context support is very extensive, and is far more complete and useful than EJB’s Stateless and Stateful beans. Plus, it finally gives us a standard between Request and Session scoped.
- CDI’s integration with JSF is far better than EJB’s (ever had a manually remove a Managed Bean from scope because its’ Stateful bean has completed its’ lifecycle? Come on!).
- CDI’s event mechanism provides for extensibility and easy, lightweight asynchronous processing.
- There’s no such thing as CDI Lite 🙂
That’s not a short list, and admittedly, it’s very early to make claims like this… after all, the spec has just finally been approved, we have yet to fully see the quality of the implementations (three that I know about, Weld, CanDI and OpenWebBeans — hey, how come they got to keep the name!?), we have yet to see how the closed-source vendors will handle it, etc., but when it comes down to it, the CDI spec is simply better suited for POJO-style development, using Object Oriented core design principals, and it was designed specifically with this in mind… Contrast this with EJB, which has over a decade of cruft to carry along with it, and actually prevents the use of OO techniques altogether (historically more-so than today, but it’s still an issue), and I think the future becomes fairly clear… All-in-all, I see it as great news for the Java EE platform…
One final caveat, though — EJB has risen from the ashes before, specifically with the 3.0 version… if the vendors still feel the need to continue to push EJB, then who knows what we’ll see 🙂