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.
(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
Nicolas Frankel replied on Wed, 2010/11/17 - 2:28am
in response to:
Nicklas Karlsson
Nicklas Karlsson replied on Wed, 2010/11/17 - 3:05am
in response to:
Nicolas Frankel
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
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
Witold Szczerba replied on Sat, 2010/11/20 - 2:05pm
in response to:
Alexey Tyutchev
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 ... ;)