Home > JavaEE > Why CDI won’t replace Spring

Why CDI won’t replace Spring

CDI is part of JavaEE 6 and that’s a great move forward. Now, there’s a standard telling vendors and developers how to do DI. It can be refined, but it’s here nonetheless. Norms and standards are IMHO a good thing in any industry. Yet, I don’t subscribe to some people’s points of view that this means the end of Spring. There are multiple DI frameworks around here and Spring is number one.

Why is that? Because it was the first? It wasn’t (look at Avalon). My opinion is that it’s because Spring’s DI mechanism is only a part of its features. Sure, it’s great but Guice and now CDI offers the same. What really sets Spring apart is its integration of JavaEE API and of the best components available on the market that are built on top of DI.

A good example of this added value is JMS: if you ever tried to post to a queue before, you know what I mean. This is the kind of code you would need to write:

Context context = new InitialContext();

QueueConnectionFactory queueConnectionFactory = (QueueConnectionFactory) context.lookup("myQConnectionFactory");

Queue queue = (Queue) context.lookup("myQueue");

QueueConnection queueConnection = queueConnectionFactory.createQueueConnection();

QueueSession queueSession = queueConnection.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);

QueueSender queueSender = queueSession.createSender(queue);

TextMessage message = queueSession.createTextMessage();

message.setText("Hello world!");

queueSender.send(message);

Now in Spring, this is configured like so:

<jee:jndi-lookup id="queueConnectionFactory" jndi-name="myQConnectionFactory" />

<jee:jndi-lookup id="q" jndi-name="myQueue" />

<bean id="jmsTemplate">
  <property name="connectionFactory" ref="jmsQueueConnectionFactory" />
  <property name="defaultDestination" ref="q" />
</bean>

I don’t care it’s shorter event though it is (but it lacks the code to send the text). I don’t care it’s XML either. My real interest is that I code less: less errors, less bugs, less code to test. I don’t have to write the boilerplate code because it’s taken care of by Spring. Sure, I have to configure, but it’s a breeze compared to the code.

This is true for JMS, but equally for Hibernate, EclipseLink, iBatis, JPA, JDO, Quartz, Groovy, JRuby, JUnit, TestNG, JasperReports, Velocity, FreeMarker, JSF, what have you that is the best of breed (or at least on top) of its category. Morevover,  if nothing exists to fit the bill, Spring provides it: look at Spring Batch for a very good example of a framework that handles the boring and repetitive code and let you focus on your business code.

Do Guice or other frameworks have such integration features included in them? No, they are pure, “untainted” DI frameworks. As such, they can easily be replaced by CDI, Spring not so much.

email
Send to Kindle
Categories: JavaEE Tags: ,
  1. Claus Hausberger
    December 9th, 2010 at 18:40 | #1

    That comparison is flawed. Spring DI gives you not advantage for JMS. It is the JMS Template that makes the ugly JMS API easier.
    With the Seam 3 JMS CDI Extension, you can also have it a lot easier.
    http://seamframework.org/Seam3/JMSModule

    You cannot compare Spring DI + JMSTemplate with CDI alone. You have to compare it with CDI + Seam 3.

    Claus

  2. December 9th, 2010 at 18:42 | #2

    Correct. But until all Spring templates are available in CDI extensions, no replacement.

  3. Yannick Majoros
    December 6th, 2011 at 10:28 | #3

    @Nicolas Frankel

    Well, you’ve got MDBs and jndi resource injection in standard Java EE. So, there is a quite good (better?) standard replacement.

  1. No trackbacks yet.