Although they are competitors, their approach and philosophy are radically different.
Spring aims to promote best-of-breed, mix-and-match, use-only-what-you-need kind of development, and portability across all Java EE servlet web servers (most notably Apache Tomcat). That is, because the application server is Spring itself.
Java EE on the other hand, gives you the full package. It has changed a lot now with Java EE 6, in that you don't have to use all of Java EE's components to use Java EE 6. The powerful-ness of Java EE 6 comes from the standard specification of technologies, which is also its weakness: it's not really meant to be flexible.
Now when I'm talking Java EE 6, I meant the components for a web application, which are: Servlet 3.0, EJB 3.1, CDI, JSF 2.0 + Facelets, JPA.
However when I'm talking Spring, I'm mostly talking about Spring Framework, and less of the rest of the Spring Portfolio (e.g. Spring MVC, Spring Web Flow, Spring Security, etc.)
Why I mentioned that, is because there is a noticeable shift from SpringSource, the maker of Spring Framework.
In its Spring Framework version 2.5, Spring is making developers enjoy the most of Java EE 5 with:
* ability to deploy on any servlet container (since Spring "application server" is embedded)
* choice of backend implementations (JPA vs. Hibernate)
* easier to use templates to use an API (e.g. HibernateTemplate)
* enabling dependency injection to any web framework
However, recent APIs and specifications reduce the significance the above benefits of using Spring.
For example, if you're using JPA (Java Persistence API), there's not much gain of using JpaTemplate to standard JPA API. This is compared to the gain of using HibernateTemplate to Hibernate API.
In fact, JpaTemplate will make your application *less* portable. Which is what you want out of Spring. Strange, isn't it?
CDI (Java Context and Dependency Injection aka JSR 299) and Bean Validation (JSR 303) specs make this matter worse for Spring.
CDI is not only a better dependency injection than Spring, but it's a standard (Spring's XML format and annotations are always proprietary). Moreover, Spring doesn't (yet?) support CDI.
Bean Validation makes Spring MVC's validations look ancient. You can use Bean Validation with Spring using Hibernate Validator, but it's not an integral part of Spring.
Perhaps this happens because SpringSource is focusing more on its corporate strategy than the Spring philosophy.
With SpringSource always expanding its portfolio of technologies, they're now a Java application server company and infrastructure provider (with parent company VMware). Surely it's in their best interest to lock-in customers with proprietary technologies than open specifications?
Corporate politics aside, both Spring and Java EE are actually converging when you compare it with a few years ago. You can write code that work in both Spring and Java EE environments. Fortunately, the part that you still need to get specific on is only configuration... i.e. Dependency Injection.
Beyond that though, it's a completely different arena. You can assume Java EE 6 apps use JSF 2.0, but who knows what eccentric web framework is used in a Spring app?
Spring promotes Spring MVC, but it's not the only choice. Even if it's Spring MVC, there are so many ways to configure a Spring MVC app. Even more when you add Spring Web Flow. It's too flexible!
A Java EE 6 application server enables easily deployment of Java EE 6 apps. However, you don't always have to use a Java EE 6 server to use a technology from Java EE 6. For example if you use CDI, you can use an open source implementation like Weld, and run your app in Tomcat.
In the end, who will win: Spring or Java EE? Let me know what you think in the comments.
Jee 6 new functionalities are a great move towards flexibility. In my opinion spring is getting too complicated and jee 6 is becoming easier. Besides of that jee 6 is a standard with oracle pushing it further, so stick with jee 6.
ReplyDeleteMasiar
> jee 6 is becoming easier.
ReplyDeleteSpring Roo and Grails (based on Spring framework) easier.
JSF 2.0 - much better than JSF 1.х
Facelets - terrible, unfriendly to user (and search engines) technology.
i :
ReplyDeleteJava EE 6 is easier than Java EE 5, and it's competitive with Spring Framework.
JSF and Facelets are both Java EE-related technology, and usable with Spring to some extent.
What I most of the time need is declarative transactions. Since CDI doesn't support that (yet) I have to choose between CDI, EJB, JPA and a JEE Container or Spring and JPA running in a Webcontainer (Tomcat).
ReplyDeleteIf CDI supports declarative transactions it will be the killer of Spring but also of EJB's ;-)
dseiler: Indeed.
ReplyDeleteIf you need declarative transactions you either choose Java EE stack (CDI+EJB) or Spring. With Spring you get only a subset of CDI for the moment, but as a substitute you gain access to all of Spring's DI capabilities.
"The powerful-ness of Java EE 6 comes from the standard specification of technologies, which is also its weakness: it's not really meant to be flexible." That'll always be the issue with JEE. In only couple of years JEE 5 became obsolete and companies need to spend more and buy new licenses for a JEE 6 compatible app server as well. And I’m not talking GlassFish or JBoss here, because most developers have no choice but to "stick" with an existing container, like WebSphere or WebLogic. Those guys on the other hand are notorious for being so slow in upgrading to latest specification (WAS 7 for example is still on JEE 5), so you’ll get stuck with them as well. Spring on the other hand will allow you to upgrade much easier.
ReplyDeleteSure JEE. It was always right to follow open standard, instead proprietary API (Spring) from one commercial vendor, sitting on their lock-in (SpringSource).
ReplyDeleteI think we have to expect "Spring Hell" in two-three years, where this thing will be supercomplicated, bloated and even more messed up. It is already very complex and bloated. Those XML^H^H^H Java programmers get confusing of what do they do: are they configuring their Java code through XML or they are coding XML through Java config. Ridiculous.
There was always a strange thing about java: nobody use built-in solutions. There is a logging api. But everybody use log4j. With apache commons logging. Why? Because "it is more flexible". Nobody ever need it, but Guru said "it is cool", so we use it.
ReplyDeleteThere are filters in servlets. But everybody use struts+interceptors. There is JSP + JSTL, but they use freemaker, velocity and so on.
There is built-in security, but they use spring security.
There is CDI, but they use spring DI.
Looks like people just got in alternative technologies and it is hard to move to pure java-ee)
@Ilya I don't usually reject opinions but I'm afraid to say that all your points are weak.
ReplyDeleteLog4j actually came before java.util.logging. JUL tries to be both the API and the implementation, and unfortunately it sucks at both. Logging API done right is SLF4J, and had SLF4J's designers designed JUL, we'd all be using "JUL" (SLF4J) by now.
It's not the coolness factor, but rather the technical benefits of the underlying technology. Unfortunately the specs seem to be stuck in stone, not evolving.
There are specs that are use as it is, and they set an example of good spec, as opposed to just "write the standard and others must follow" mentality.
JAX-RS / JSR-311 is one such excellent example. Restlet, RESTEasy etc. all came before JSR-311, but when JSR-311 is announced with Jersey, very few are complaining (about the API, especially with improvements in version 1.1) and nowadays you'll be surprised if any Java developer wants to use proprietary Restlet/RESTEasy API instead of standard JAX-RS.
Why JAX-RS succeeds? Because it is a good spec (technically). And it doesn't sacrifice flexibility like JUL did. You don't have to use Jersey, you can use Restlet, CXF, RESTEasy etc.
In security context there is JAAS, which is also a good spec. Many projects use JAAS, with or without another security framework.
There is no reason to "hate" Java EE specs in general. But the specs need to be practical, and evolving quickly. When JPA 1.0 came out many people want to adopt it, but some are held back by its limitations. JPA 2.0 makes it much more attractive when compared to, say, Hibernate API.
JSF 1.0 did suck. Later revisions suck less and 2.0 sucked even less, and giving more reasons for developers to just use it. Did you realize that ICEFaces 2.0 and JBoss AS 6 had just been *recently* released?
The development pace of supporting tools/libraries for CDI and JSF 2.0 does feel slow to me, and probably for other people. It's one of the reasons why developers choose (stable) Spring technologies over "a new Java EE spec implementation still in beta for the past few months or even more than a year".
Hi,
ReplyDeletesome corrections:
- The JpaTemplate and the HibernateTemplate should not be used because of the additional dependency on Spring. Instead you can use the plain JPA/Hbernate APIs also with Spring.
- JSR 303 (Validation) is supported in Spring.
I personally wonder why you call CDI superior to Spring (you give no reasons). Also I wonder why you think the freedom of choice for web frameworks is a problem - there are a lot of web frameworks so I beleive they all have a nice.
You might also want to look at http://jandiandme.blogspot.com/2010/10/spring-vs-java-ee-and-why-i-dont-care.html for my perspective....
We just spend a year working on EJB 3.1 on Glassfish with JPA2.
ReplyDeleteWe have recently switched to Spring 3.
While EJB is now "light" the containers add way to much overhead - now happily bootstrapping much faster, and using far,far less memory memory.
Spring implements the CDI. I use the CDI annotations with Spring.
ReplyDelete> You can assume Java EE 6 apps use JSF 2.0
ReplyDeletePlease don't assume that. You can use any web framework you want as you do with Spring.
While I consider Stripes and Wicket the best web frameworks, Spring MVC and Struts 2 are still in the lead:
http://www.google.com/trends?q=Stripes+Framework%2C+Spring+MVC%2C+Struts+2%2C+JSF+2.0%2C+Apache+Wicket%2C+Apache+Tapestry&ctab=0&geo=all&date=all&sort=1
I agree with the rest of your review and personally believe that CDI and Bean Validation are indeed among the most compelling features to convince developers to return to Java EE.
EE6 is the definitive answer whenever someone says that EE is too heavy or too difficult. Spring was a good solution prior to EE5 and now with EE6 Spring will ultimately become a legacy technology.
ReplyDeleteJSF should not be viewed as the only Web framework for EE applications. Wicket, for example, can run perfectly well in an EE6 container. If you are interested, please read my articles on this subject beginning with this one - http://jeff-schwartz.blogspot.com/2011/03/java-ee6-wicket.html.
Jeff
@samaxes "[...] I agree with the rest of your review and personally believe that CDI and Bean Validation are indeed among the most compelling features to convince developers to return to Java EE [...]"
ReplyDelete+1
Spring made things easier when it was first developed. At this point it is just an additional dependency that does the same things Java EE already has but in a more complex way.
ReplyDeleteDiscover top-notch Webflow nonprofit templates to elevate your cause. Engage supporters and boost donations effortlessly. Try them now!
ReplyDeleteflowgiri
Spring is a lightweight and versatile framework, while Java EE (Enterprise Edition) is a robust and standardized platform for large-scale enterprise applications.
ReplyDelete