Nicolas Frankel is an IT consultant with 10 years experience in Java / JEE environments. He likes his job so much he writes technical articles on his blog and reviews technical books in his spare time. He also tries to find other geeks like him in universities, as a part-time lecturer. Nicolas is a DZone MVB and is not an employee of DZone and has posted 228 posts at DZone. You can read more from them at their website. View Full User Profile

Why CDI Won’t Replace Spring

11.17.2010
| 13992 views |
  • submit to reddit

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.

 

Published at DZone with permission of Nicolas Frankel, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Nicklas Karlsson replied on Wed, 2010/11/17 - 2:02am

Interesting article but I think you're missing one point (that Gavin King likes to point out) the core of CDI isn't injection (like you said, many have done it before). The true, hidden additional value lies in the extensions ecosystem. You could for example write something like http://docs.jboss.org/seam/3/jms/latest/reference/en-US/html_single/ and it wouldn't be a *Seam* extension, it's a *CDI* extension. Sure, everyone can be a Spring developer and write wrappers around tech X but it's still going to be non-portable. Cheers, Nik

Nicolas Frankel replied on Wed, 2010/11/17 - 2:28am in response to: Nicklas Karlsson

Good point, though I have heard much about extensions but not seen one into action. If you could point me in the right direction...

Nicklas Karlsson replied on Wed, 2010/11/17 - 3:05am in response to: Nicolas Frankel

Have a look at http://groups.diigo.com/group/cdi-extensions Of course, since CDI is young, the extensions ecosystem is still in development.

Jose Maria Arranz replied on Wed, 2010/11/17 - 3:59am

Sorry for the rant Nicolas, I'm going to be a bit rude

First of all you are missing the code to send the message, so you cannot claim you are reducing the boilerplate based on this example, you know the code is basically THE SAME.

Said this we have LOST the head, Dependency Injection is JUST FOR DEPENDENCY INJECTION, IT HAS NOTHING TO DO WITH THE CONCRETE CLASSES WE ARE MANAGING.

Spring is A LOT OF MORE THAT DEPENDENCY INJECTION, it provides TONS of wrappers AND artifacts that in fact they could be used easily OUTSIDE ANY DEPENDENCY INJECTION framework, furthermore you can use them IN ANY OTHER DEPENDENCY FRAMEWORK. Dependency Injection is just the glue is JUST AN ALTERNATIVE TO CODE THE SAME IN PLAIN Java.

You cannot compare CDI with Spring with a concrete example using the Spring's JMStemplate that it has nothing to do with DI. And of course you cannot compare Spring as a whole with Guice just a tool for DI.

You can compare the full stack JavaEE vs Spring, and the comparison is not going to be fair on number of lines of code because Spring defines many templates (wrappers) ON TOP of JavaEE standards to reduce as possible the needed API and to provide a unified API integrating other non-standard similar libraries, and it is FINE if these wrappers do the job.

If you are going to write less is because of using these Spring templates, and as said before you can use them with CDI, Guice or just PLAIN JAVA!

Take a look, it is JUST JAVA, no XML, no annotations!

http://static.springsource.org/spring/docs/3.0.x/javadoc-api/

Stop this crazy race to nowhere and mix JavaEE and Spring when you like where you like, but is very very important to differentiate dependency injection and libraries.

Because Spring is not tied to industry standards you are EVER going to find more and more Spring technologies ON TOP of Java standards providing some value added, therefore Spring is EVER going to be MORE than JavaEE.

 

Bart Kummel replied on Wed, 2010/11/17 - 9:30am in response to: Nicolas Frankel

Have you checked out MyFaces Extensions CDI aka CODI? See https://cwiki.apache.org/EXTCDI/

Witold Szczerba replied on Wed, 2010/11/17 - 2:46pm in response to: Jose Maria Arranz

Jose is right.

Last time I used Spring libraries - it was in application with Guice DI, which I choosed because I like it much much more than Spring DI.

Liam Knox replied on Wed, 2010/11/17 - 11:16pm in response to: Nicklas Karlsson

When has anyone ported anything from one J2EE application server to another?

When has traditional J2EE applications servers ever improved anything in application development?

 The shear adoption of Spring proves the failure of traditional J2EE. The rest, EJB3 etc. is pure plagarism, and weaker also.  Spring won't just disapear because a commitee plagerises and formalizes a JSR.  The reason technolgy gets replaced is because something else adds value enough for a company to adopt it. 'new' J2EE doesnt do that

All this Java is dead, Spring is dead, yada, yada, yada, is the most boring and worthless debate in the community.  Java's mortality will easily out stay the very mortality of the people who are prediciting is death. FACT.

Alexey Tyutchev replied on Thu, 2010/11/18 - 4:18am

Sorry to say this, but it is like comparing apples and oranges. Spring has SO many helper classes - for JPA, JDBC, JMS...They just HELP...code for sending JMS is EXACTLY the same, but instead of writing it by yourself, you relay on Springs code. You can wtite same JMSCDIHelper that will do exactly the same as Springs JMSHelper...And here you comparing pure CDI with WHOLE PLATFORM.

Witold Szczerba replied on Sat, 2010/11/20 - 2:05pm in response to: Alexey Tyutchev

You can wtite same JMSCDIHelper that will do exactly the same as Springs JMSHelper.

There is nothing Spring DI specific in JMSHelper, so saying that one can write JMSCDIHelper is pointless. 

That is exactly what people say here - the Spring DI is one thing (which I would like finally to retire) and the Spring libraries and helper methods are something else. The wisdom of Spring developers is that they do not tie all that libraries with Spring DI... well, after all, the entire concept of inversion of control by dependency injection is transparent to API.

Eduard Korenschi replied on Tue, 2012/11/27 - 2:58am in response to: Witold Szczerba

You're right ... and I hope I'll see the day when Spring will be just a set of CDI extensions ... ;)

Slim Ouertani replied on Mon, 2014/07/21 - 6:26am in response to: Nicolas Frankel

4 years later.... 

After JEE7 :  JMS and batch examples are not relevant, should this article be updated or just reverse the title?


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.