Niklas has posted 30 posts at DZone. You can read more from them at their website. View Full User Profile

A technology decision making process: Java EE 6 vs. Spring Framework

  • submit to reddit

In the last few month we've went through this decision making process: which technology stack to choose for enterprise development on the Java platform? There are various alternatives. However, the ones we've discussed intensively were: Pure Java EE 6 Stack vs. Spring with Java EE. The following blog article summarizes key issues I found interesting when you consider one of those technology stack options. I will not try to convince somebody to choose either of the two. It's the decision making process and the key arguments that are important to me and that I want to share.

What is a "standard"?
The word "standard" was a very important one in our discussions, especially for executive management. I think it gives decision makers a warm feeling with regards to protection of investment. But what is a standard and what can we consider as standard in the Java ecosystem? Mirko Novakovic, founder and board member of codecentric AG, wrote a very interesting blog article called: "Java EE vs Spring. Or: What is a standard?" Mirko states the following:
- for him a standard is something that is established, accepted and dominant- following this definition only some of the Java EE APIs like the Servlet specification can be considered as a standard, because they are widely applied in the Java production technology landscape- he looks in the past saying that there was little investment protection in some of the Java EE Standard APIs, like for example the EJB specification (massive API changes over the last decade)- he also claims that JPA and JSF in their 1.0 Versions weren't sufficient to fulfill the technical requirements in large scale enterprise development projects- he looks at CDI as another young standard that needs to proove a long term stability before it can be considered as a standard IOC mechanism in Java enterprise applications- consequently, his conclusion for the moment is: Sping and Hibernate are still "the de-facto" standards for Java enterprise development
Mirko describes a valid perspective. Another valid perspective is the following: all (and only) APIs specified and released in a Java Specification Request (JSR) can be considered as standard. Application server vendors build their products according to these JSRs. Therefore, Java developers can build web applications that run on any application server plattform if they use these standard APIs. In Java EE 6 they can build enterprise scale web applications without any further dependency to a third library. The result is a very light weight web application (WAR or EAR file) that only contains the code that you have developed. That's the Java EE case and that's also valid and conclusive.
When you have to decide which APIs to use in your programming model, what would be the most important thing to you? There are lots of decision parameters like simplicity, completeness of the API, prooved production stability and many more. We have made a long list of parameters in our study. Some of them were more important then others, those were: maturity level of the API, supplier independence, production readiness, investment protection and shared judgement.
Life cycle of Standard APIs
Our assumption is that every API walks through an idealized life cycle when it enters the Java EE Standard (we observed that in the past). Those phases are: Newby, Storm, Stabalize, Mature, Dead. The first (Newby) Version 1.0 of the Standard API has little functionality. Typically it is not sufficient to fullfill the technical requirements for functionality and performance of large scale development projects. This is Mirko's argument against CDI or JPA 1.0. Some use these APIs, but they also have to program many work arounds to get the full functionality they need (e.g. for 2nd level caching in JPA 1.0). The lessons of these phase make their way into the subsequent API versions and therefore - for a while - the API gets instable. Functionality is added, APIs are reduced adopted, simplified and so on. This turbulent and uncertain storming phase leads to increasing migration costs if customers want to follow the standard. Even if the 2.0 Version is downwoards compatible, using the nice new features instead of the many workarounds means refactoring efforts. If the API is not downwoards compatible API changes enforce migration effort, there is no choice. After a while however the API gets mature and these refactoring costs decrease, the API entered the phase of stabalization. A mature API has constantly low costs of migration and refactoring because no fundamental changes are applied. After a while a technology is not used anymore, because it's replaced by other innovative APIs. The technology is dead - there is no investment anymore in these APIs, the community stopped the project. Image 1 shows the idealized API life cycle.
Image 1: Idealized life cycle of Java EE APIs
The key assumption of the life cycle model is: the earlier you decide to use an API standard the more refactoring cost you may probably pay when the API is enhanced in subsequent releases. So the advice is: you have to judge the state of the (Java EE) API in the life cycle. Then you decide whether you want to use mature APIs and lower refecatoring costs. Or whether you want to be one of the pioneers using the technology strait away. One advantage of early adoption may be early achievement of higher development efficiencies or higher integration with other standard APIs or developing consulting knowledge.
We have decided to use mature APIs only, we do not want to have the migration costs associated with "Newby" state APIs. Our level of trust is rather low, because we have suffered a lot in the EJB era. If we look at the history of some Java EE standards, the changes associated with stabilization of the API were enormous. Therefore we prefer to wait until the API is mature and is a prooven technology for large application systems in production. If we believe the Java EE API is mature we consider to use it.
Independence (development, operations and OE supplier)
Another important factor in architectural decision making to us: we want to maximize flexibility for subsequent architecural, design or implementation decisons. What do I mean by that? If, for instance, you choose a technology stack that is part of your application server then your application development department, your infrastructure people and your original equipment (OE) vendor will have a very close relationship. Why? Because new application server releases consist of new API versions that you use in your business application. The consequence is that you may have to change your exisiting code when you decide to use a new version of your application server. All this reduces flexibility.
Also, the OE vendor may rush you to migrate because "if you want to have this unique monitoring or integration feature of our application server you will have to use the very latest release of our XY Java EE server". OE suppliers often have an inherent interest in that they want you to use their latest releases. For them it's simply cheaper to support fewer production releases. It generates less maintenance costs and higher consultancy revenue for them.
We run over 50 Java EE applications in production. For the described reasons it is very important to us to stay independent of the runtime infrastructure. Therefore we often prefer a "layer between" our business applications and the application server. In other words: we usualy do not use Newby APIs directly, we usually have a wrapper API hiding them (see Image 2). This wrapper is used as API to build the business applications. The wrapper API could be the Spring Framework, or your own set of custom framework APIs. This way it's easier and more efficient to make required changes when we moove to new application server releases or Java EE versions respectively. The wrapper absorbes Java EE API changes and saves us from the burden to change 50 applications. Instead, we do the changes once in a central place. Our development groups are not affected by application server upgrades. OE suppliers and the Java Communication Process (JCP) do not influence our decisions and efforts.
Production-readiness of infrastructure (or: now or later?)
Is there a production ready release of your application server that implements the new Java EE 6 standard? In our case (IBM WebSphere) we do not have any Java EE 6 Version available on Z Series. So there is only little sense in thinking about Java EE 6 if we can't run our applications in production yet. You have to decide whether you want to use a technology now or later when it is available. CDI (JSR 299/330) as IOC mechanism for example is not mature enough for large applications. Therefore you may have to choose alternatives like the Spring Framework or Google Guice to do the job, if you want to have the (effeciency) value brought to your clients now.
Investment Protection (or: downwoards compatability)
I already mentioned it earlier: using the Java EE API directly for many production applications, may be 50 or 100, will probably create lower flexibility in design and implementation decisions. The same arguments apply when we look at investment protection. To me investment protection is a lot about low technical (refactoring) costs over a specific period of time. You want to spend money to achieve business value, you want to concentrate on implementing business functions. You do not want to spend to much effort in technical necessities (e.g. release upgrades, platform migrations, develop custom APIs). To achieve this choosing the right development API is critical. According to our life cycle model a good option is to choose APIs at the beginning of a long maturity phase in the life cycle. This lowers refactoring cost, thus increases investment protection.
We have already explained that Java EE does not only provide mature APIs. CDI, for example, is not mature in its JSR 299/330 version. A possible solution to that dilemma is to combine APIs from different sources, you could configure your own set of APIs for your business applications. If you use your own set of real standard APIs, then you protect your investment. I am saying your own set because you may use a mixed technology stack (Image 2): some mature Java EE APIs (e.g. Servlets, JPA 2.0), some de-facto standards (e.g. Spring IOC) and some proprietary custom APIs that you have developed as wrappers around Newby Java EE APIs. The most important thing is that those APIs support  downwoards compatability for your production applications. You have to find a set of APIs that saves you from large migration efforts when you want to move to new Java EE application server releases.
Image 2: Mixed technology stack for Java enterprise development

Shared judgement
Something I do when I make decisions is shared judgement. What do other experts think? What ideology do they have? What interest do they have to make the one or the other recomendation? If you look at the large Java enterprise development framewors like Spring Framework you can observe that they use standard Java EE APIs, but only those that they consider as being mature. That's a good hint for me whether or not to use a specific API. It does not metter whether you look at Spring, or whether you observe other frameworks. The point is that you can validate your opinion against the opinions of other prooved (preferably independent) experts.
There is a long list of parameters when you decide what technology stack to use. Those I have described in this article were very imprtant ones in our decision making process. Our conclusion is that the best way forward for now is to use a mixed technology stack. Some APIs are de-facto standards, some are Java EE standards, others are custom APIs that we have developed. Our main objective is to stay flexible at a constantly low level of refactoring costs over time.
A last thought on standards: Have you ever asked yourself whether it's really important to follow the standard? Sometimes I have the impression that - to some people - using a standard is something that is close to absolute truth, something that is a universally right thing to do. Water is wet, the sky is blue and using a standard is right. You know what I am trying to say? How did all those de-facto standards like Spring and Hibernate became standards? The answer is: because someone had the courage to use it and others (including Java EE) followed. A "standard" is what a large part of the community uses to run large applications in production. A standard is not necessarily a Java EE standard. In the past Java EE standards followed the de-facto standard frameworks (e.g. Hibernate, Spring). There is a high probability that any new technologies first reach a certain level of maturity in open source frameworks. Then they will become Java EE standards. That's because the vast majority of Java technology innovation has its source in the community - at least for the last decade.



Published at DZone with permission of its author, Niklas Schlimm.

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



André Pankraz replied on Tue, 2012/01/17 - 3:11am

Maybe I'm one sided too, but for an "I will not convince..." this article sounds more like an "We would pefer to use Spring but Management says no". JEE parts not mature this, JEE standards not important that, JEE past problems there...Spring de-facto standard, always perfect etc. With a little bit more balance in the examples and arguments - it would be much better decision making.

Neither JEE nor Spring are real international de-jure-standards. JCP is a more than an industry- or defacto-standard, multiple organizations commited in an official process to a specification and a reference implementation. Many commercial and none-commercial implementations exist. Thats a good thing. And CDI isn't exactly completely new....experiences from Seam, Guice etc. went into this - to speak of immaturity because of some bugs in Weld or some features they also would like to add is really harsh.

I would say, Java wouldn't be such successful on server side without JCP, that begins with standardized Servlets and all that. Yes, for complex business apps you cannot simply change the app server and expect that this works without some efforts. Frankly I have never seen in praxis that someone really wants to do that, it's not the point. 

Best regards,


Charlie Mordant replied on Tue, 2012/01/17 - 8:31am



My company is trying to replace all instances of was6/RAD with eclipse3.7/JBoss7 or Glassfish, isn't it a good solution to economize millions €?

But it's for now impossible due to the risk/refactoring/time. If it was spring, even 2.0 version, we could have moved to any appserver: tomcat, whatever even osgi runtime and spr 3.1 version in a minute, or in incremental  way.


To my point of view Spring architecture takes a lot more implication/knowledge to be up and running, but it's a very good long time investment.


Regards from a man that was catapulted to the architecture evolution service...

André Pankraz replied on Tue, 2012/01/17 - 9:26am in response to: Charlie Mordant

So you have a case where an app server switch would be useful, licence costs are an important decision factor.

I don't think that a complex Spring 2.0 App at e.g. commercial ServletExec from NewAtlanta (to have a comperable example) can simply be migrated to Spring 3.1 on top of Tomcat 7 and JDK 7 etc. The risk is always there.

I don't argument against Spring here, decide for one or the other - both work. The examples and arguments sounded a little bit lopsided to me.

Mike Dzone replied on Tue, 2012/01/17 - 10:40am

Usually the choice is very simple.  Do you want to hack together an enterprise server using spring/tomcat or do you want to use real enterprise server technology?  The latter is always the better choice, especially with EE6

Henk De Boer replied on Tue, 2012/01/17 - 11:55am

But it's for now impossible due to the risk/refactoring/time. If it was spring, even 2.0 version, we could have moved to any appserver: tomcat, whatever even osgi runtime and spr 3.1 version in a minute, or in incremental  way.

That's a bit of a nonsense comparison. In the case of Spring you aren't migrating from Spring at all but simply staying on Spring. You're also barely moving to another appserver, since you're not using anything more from the appserver than the Servlet API and the underlying JDK. (in most cases, Spring war archives are completely self-sustaining and contain everything)

Similarly, you can perfectly well move JBoss AS or GlassFish to another JDK implementation. Last time I checked both run fine on the Oracle one and JRockit (which is now from Oracle as well, but that aside).

Should you ever want to migrate away from your current Spring implementation, perhaps because Rod Johnson really went too far this time, or because VMWare introduced some policy you really aren't happy with, you're stuck. There simply isn't another Spring implementation.

But if you decide that JBoss is really going too far with vilifying established Java EE concepts (like JNDI lookups, embedded resources, etc), there's always GlassFish to migrate to. Or TomEE if you're on the web profile. Or Geronimo, or Resin, or ...

Nobody says it's as simple as just deploying your EAR or WAR to the other AS, but it's doable in a relatively short amount of time. It's a completely different thing than rewriting your code from Spring to Java EE, or from say Spring to .NET. 



Shiva Anand Red... replied on Tue, 2012/01/17 - 9:16pm

I have used quite a few AppServers from IBM WAS V5.1 to WAS 8.0 (apart from tomcat, jetty, glassfish). Based on experience I would go with mixed techonlogy.  Thou' I would switch to JEE 5 + third party.  Instead of just sticking with Spring or Hibernate.

If Java can change so much, so can third party libraries. Also pointed noted is that there is DEAD time for everything :). My project has burned it hands too many times and is neck deep in trouble. So do consider a gradual upgradation instead of justing using Spring x version and leaving it for long time.


Jonathan Fullam replied on Tue, 2012/01/17 - 9:25pm in response to: Mike Dzone

Do you really consider using a Spring a "hack" approach to enterprise development? Have you had any experience with Spring? It is extremely elegant, lightweight, portable, and complete. Would Spring have had as much success if it was a hack? Don't forget that EE6 has been greatly influenced by the success of Spring. You should definitely give Spring a try and you will be surprise at how much more productive you become.

John Waterwood replied on Wed, 2012/01/18 - 4:48am in response to: Jonathan Fullam

Jonathan, I also think Spring is a bit of a heck in the sense that it implements a full AS, and uses the original AS only for bootstrapping.

In my book Spring is not so elegant. It's functional, but it's largely a lot of functionality just thrown together with not always consistent behavior. The programming model originally tried to classify programming concerns as "configuration", requiring tons of verbose XML that needed to be kept carefully in sync with the java based code.

Revolted by the Spring XML-hell, Java EE introduced a much saner annotation based approach. Spring has only recently seen the light as well and copied the Java EE approach. Then Java EE introduced type-safe injection, while in Spring injection was always string based. I think the Java EE way is much more elegant.

Java EE implementations can also be much more lightweight than Spring. Check for instance TomEE and Resin. These fully implement the Java EE 6 Web profile (containing the first class web framework JSF, orm JPA, injections CDI, security and transactions EJB and JTA, ...), in some 25MB!

Now Spring. You need to download all parts seperately, which is well over 100MB, and then you still need to download Tomcat, Hibernate, Atomica, etc.

I'll take Java EE over Spring any day!

Karl Peterbauer replied on Wed, 2012/01/18 - 3:15pm in response to: Jonathan Fullam

Several mistakes:

1. Spring is not "lightweight". It's massively pervasive. Most of the code developed with/for Spring is tied to Spring forever. If you opt to use annotation-based wiring, JDBC-/JPA-Templates etc., then nearly each and every piece of code will have direct Spring deps. If not, then you end up having a huge, fragile Spring-XML containing the wiring. And finally, you will have tons direct Spring deps in your testing code. 

2. Spring is not "elegant". The concept of IoC is elegant, and Spring really deserves a place in the Java Hall of Fame for pushing this concept forward. But the Spring API itself is huge (2500+ classes), confusing, and full of strange abstractions (abstractions of abstractions etc.) and absurd naming conventions (SimpleBeanFactoryAwareAspectInstanceFactory, wtf). You should definitely give JEE 6 CDI a try, and you will be surprised how the phletora of Spring abstractions can be condensed into a few.

3. Spring is not more "portable" than any other JEE technology. I'm using Spring for years now, and my experience is that a migration from one JEE container to another (or another major version) is always a hassle. 

4. Spring is not "complete", it does not even aim to be complete. For example, Spring does not provide a solution for transactionally accessing multiple databases (XA). It's made for single-database apps running on Tomcat, period.

Many of us will have to stick to Spring, since many companies stick to plain old Tomcat as platform, but technically CDI blows the hell out of Spring. 

Niklas Schlimm replied on Thu, 2012/01/19 - 10:08am

Some clarification needed here 'cause there is too much bias in the last comment:

1. Spring is not "lightweight".

-> but it's downwards compatible, right? Let's wait a few years and look at the CDI libs then ;-)

2. Spring is not "elegant". 

-> this is nonsense cause you have three super simple and elegant DI concepts in Spring

3. Spring is not more "portable" than any other JEE technology. 

->  how about EJB 2.1?

4. Spring is not "complete", it does not even aim to be complete. For example, Spring does not provide a solution for transactionally accessing multiple databases (XA). It's made for single-database apps running on Tomcat, period.

-> hm, that's interesting ... we just run the Spring stack in a distributed tx environment

No doubt CDI is cool stuff, I just prefer Spring for several reason. One is that I can deploy it to my WEB-INF/lib and control how fast I can use new features ...


Yannick Menager replied on Thu, 2012/01/19 - 9:51pm

Well, the biggest advantage of using JEE is that it is a STANDARD.

As in, if you're using some implementation of it, you can switch to any other implementation of that standard, and it should run with no (or little) changes

Spring, on the other side, is totally proprietary and you're at the mercy of springsource.

So if they decided to suddently pull a bait-and-switch, you'd end up screwed because you'd have to go through significant effort to move your code to something else, or pay whatever they ask.

Of course you could always say they're nice people and would never do such a thing...... *buzzzzzz* wrong answer, actually they've done EXACTLY THAT :

No bugfixes unless you pay for the enterprise support... nice isn't it ???

Using real standards (as in, there are many different implementations of the standard) protects you from that.

So spring might be very popular, but it's most definitely not a standard

John Waterwood replied on Fri, 2012/01/20 - 4:37am in response to: Niklas Schlimm

Niklas, you make a good point about CDI being new and that it remains to be seen what it will look like in the future. At least you implicitly "admitted" that Spring in its current form is indeed rather heavyweight.

Now this doesn't necessarily has to be a blocking reason for not using Spring. My main beef is that more than a few Spring fans still claim Spring is lightweight, just because Rod once told them this and without realizing what the word actually means.

As soon as people break through some of the old cliches (Spring is ligtweight, containers are evil), it will be much easier to do an actual comparison between the two technologies. ("container == evil" is rather nonsense indeed, as even the Spring documentation speaks about the Spring bean container)

The WEB-INF/lib deployment model is IMO the only "advantage" Spring has, and it's pretty much the thing every Spring vs Java EE discussion always deteriorates to. There was a similar discussion on the Spring 3.1 announcement blog from Juergen recently.

Niklas Schlimm replied on Fri, 2012/01/20 - 5:32am in response to: John Waterwood

Hi John, there's nothing to "admit" 'cause comparing CDI libs with Spring is dangerous in terms of "heavyweight and lightweight". Spring has three different approaches to define IoC dependencies. Pure CDI has only one. It's the only logical consequence that you need less code to do that ;-) if you take other CDI extensions on board to broaden the CDI featutes (to make them comparable with Spring IoC) then you end up with the same "weight" ...

Karl Peterbauer replied on Sun, 2012/01/22 - 8:07am in response to: Niklas Schlimm


 -> hm, that's interesting ... we just run the Spring stack in a distributed tx environment

we are talking about Spring's "completeness", and your answer is to "switch to a XA-enabled JEE container"? What's the decisive advantage of running Spring on top of a full-blown JEE 6 container? You've got CDI and XA for free without the hassles of an additional, complex layer. Seems a lot of bias on your side, just now in favor of Spring...

-> this is nonsense cause you have three super simple and elegant DI concepts in Spring 

In my comment, I clearly emphasized that Spring's IoC-concept is highly elegant. But the implementation to too much string-based, which is fixed by CDI. And large parts of the huge Spring API are arguably not elegant. Where is the bias here?



Niklas Schlimm replied on Tue, 2012/01/24 - 12:12pm in response to: Yannick Menager

You can see from the download page at springsource that you can get all the bugfixes.

Carla Brian replied on Sun, 2012/06/24 - 5:29pm

I am currenlty downloading this one. I will still search more of some tutorials on this since this is my first time encountering this application. - Mercy Ministries

Comment viewing options

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