Is CDI a good replacement of Spring?

Question

We are planning to write a web application from the scratch, it has been decided to go with the latest edition of Glassfish which complies to Java EE 6 standard, therefore we ar

Answer 1

I'm using Apache OpenWebBeans as CDI implementation and MyFaces CODI as portable extension for several projects. I'm very happy with it and I had no problems with it. OpenWebBeans currently lacks a bit in view of documentation but if you can't get something to work it's pretty easy to use the Maven Archetypes provided by MyFaces to generate simple projects with all the needed dependencies or you ask on the mailing list. It's so great if you just work on your Application and you aren't blocked by nasty bugs. I also did a lot of projects with Spring. It's ok, but if you ask what I would use for the next project the clear answer is OpenWebBeans and CODI! I prefer OpenWebBeans over Weld because OpenWebBeans is very adoptable that's great because you can customize more or less everything which isn't covered by the official CDI API/SPI and the runtimeperformance is better. And after the first project I would never question again CODI because it's very stable, they have regular releases and most of them brought great new features which improve the productivity a lot. CODI is IMHO the place which is most stable and were most innovations come from in the whole CDI land.

To answer your question: For me CDI completely replaced Spring, but you need portable extensions which fill the gaps. CDI as standard never intended to solve everything and some parts like the conversations are broken by design. The good news is that you have great projects like MyFaces CODI. CODI fixes almost all those issues.

Answer 2

Spring is more than just a dependency injection container. It also has tools for AOP, templates for use with JPA, SQL, etc. and even more.

However CDI can be used as a replacement for Spring's DI API.

Answer 3

CDI stands for "context and dependency injection", while Spring is a complete ecosystem around a dependency injection container. To compare both, you have to differentiate the comparison.

Dependency injection is handled by both containers. The main difference is the fact that CDI handles DI in a dynamic (aka: stateful) way - this means that dependencies are resolved at execution time. Spring's approach is static - this means that components are wired together at creation time. While the CDI-way might seem a bit unusual at a first glimpse, it's far superior and offers way more and advanced options (I'm writing this with the background of two productive CDI apps).

If you look at the ecosystem, the situation is different: Spring comes bundled with a lot of jars (>150), while CDI is pretty small by itself. A typical CDI-usage would be inside of a Java EE 6 application server, but you can easily make it work in a servlet engine or even Java SE. This means that using CDI makes no assumption about using Hibernate, JPA, EJB or whatever - that's up to you.

If you need more functionality, CDI comes with the concept of portable extensions (which by itself makes the API worthwile). Independent extension modules like Apache CODI and Seam 3 exist and cover topics like security, mailing, reporting and more.

To summarize: CDI is nothing like a "replacement" for the Spring ecosystem, it's rather an improvement over Spring's dependency injection mechanism. It's part of Java EE 6, so if you are on a GlasFish with Java EE 6, you should definitely go for CDI. In my eyes your question is rather: Can I replace Spring with Java EE 6? I guess my answer is pretty obvious ;-)

Have a look at Weld to get a good start...