About Kai Waehner

Kai Waehner works as consultant. His main area of expertise lies within the fields of Java EE, SOA, Cloud Computing, BPM, Big Data, and Enterprise Architecture Management. He is speaker at international IT conferences such as JavaOne, ApacheCon or OOP, writes articles for professional journals, and shares his experiences with new technologies on his blog.

Why I will use Java EE instead of Spring in new Enterprise Java Projects in 2012

The question comes up often. It came up in my new project in November 2011, too. I will use Java EE (JEE) instead of the Spring framework in this new Enterprise Java project.

I know: Several articles, blogs and forum discussions are available regarding this topic. Why is there a need for one more? Because many blogs talk about older versions of Java EE or because they are not neutral (I hope to be neutral). And because many people still think thank EJBs are heavy! And because the time has changed: It is Java EE 6 time now, J2EE is dead. Finally! Finally, because not only JEE 6 is available, but also several application servers (not just Glassfish as reference implementation). I do not want to start a flame war (too many exist already), I just want to describe my personal opinion of the JEE vs. Spring „fight“…

Therefore, I think it is very important to start with a short overview and history of both alternatives. Afterwards, I will list the differences of both and explain why these differences lead me to JEE instead of Spring for most new Java projects. I am explicitly talking about new applications. If you have to extend an existing application, continue using the existing framework!

One more disclaimer: I am talking about mission-critical Enterprise Java applications. I am not talking about a little internal application or other uncritical stuff. I also would prefer using a combination of Scala, Groovy and Clojure persisting to a NoSQL database while being deployed at a PaaS cloud service such as JBoss OpenShift or VMware CloudFoundry…

General Information about JEE and Spring

First, I want to summarize some general information about JEE and Spring:

  • In the end, both alternatives consist of several libraries which can be used by developers to create enterprise applications.
  • Both can be used in most use cases, they have very similar functionality (business logic, transactions, web-frameworks, whatever…) – they only differ in realization (e.g. declarative transactions in Spring vs. conventions in JEE).
  • You also can use only one or some of the available libraries. You can even combine JEE and Spring stuff.
  • Usually, the crucial question is: „Should I use JEE (i.e. especially EJB, JPA, CDI, etc.) or the Spring core framework (i.e. especially Spring Application Context, Spring beans, etc.) for realizing my new application? Mostly, you can choose both, it does not matter from the point of view of the end user. But you should not merge both, this only creates higher complexity.
  • There always was a debate about which alternative to choose. It is very difficult to discuss this question in a neutral way. That’s why almost all discussions end up in praising one framework and bashing the other one (I hope to be neutral in this blog post).

History: J2EE was horrible, so Spring helped!

J2EE was horrible. So much XML configuration, so many interfaces, and so lame application servers. This is why the Spring framework was created. It solved many problems of J2EE. It was lightweight, easy to use, and applications could be deployed in a web container (such as Tomcat) instead of a heavy J2EE application server. Deployment took seconds instead of 15 minutes. Unfortunately, JRebel did not exist at that time. The Spring framework is no standard as J2EE, nevertheless it became very widespread and an large community arose.

Today: J2EE is dead. JEE „stole“ the lightweight Spring ideas!

Everything started with a little shortcut change. J2EE was dead. The new shortcut was JEE. JEE 5 was born in 2006. It „stole“ many good, lightweight ideas such as „convention over configuration“ or „dependency injection“ from Spring and other frameworks. Yes, JEE application servers still were heavy, and testing was almost impossible. Nevertheless, developing JEE applications was fun with JEE 5. You did not have to write 20 interfaces when creating an EJB. Wow, amazing!

Then, in 2009, JEE 6 was released. Development is so easy. Finally! For example, you have to add only one annotation and your EJB is ready! Of course, the developers of the Spring framework did not sleep. Much new stuff was added. Today, you can create a Spring application without any one XML file as I have read in a „No Fluff Just Stuff“ article some weeks ago. Besides, several really cool frameworks were added to the Spring stack, e.g. Spring Integration, Spring Batch or Spring Roo.
Today (November, 2011), both JEE and Spring are very widespread and have a large community. Much information is available for both, e.g. books, blogs, tutorials, etc.
So, after I have described the evolution of JEE and Spring, why will I use JEE in most new Java projects?

Pros and Cons of JEE and Spring

A decision must be made. Which alternative to use in new projects? Let’s look at the pros and cons of both. I will add a „BUT“ to the Spring advantages – these „BUTs“ are the reason why I prefer JEE to Spring.

Advantages of JEE

  • JEE is a set of standard specifications, thus it is vendor-independent. Usually, several implementations exist of a specification.
  • Sustainability: Well, this is the advantage of a standard which is supported by several big players.
  • Yes, believe it or not, testing is possible! Lightweight application servers and frameworks such as Arquillian arrived in the JEE world!
  • Convention over Configuration is everywhere instead of explicit (I know that some people will disagree that this is an advantage).

Advantages of Spring

  • You do not need a heavy JEE application server, you can deploy your application in a web container such as Tomcat.

BUT: JEE application servers are not as heavy as they were some years ago. Besides, the JEE web profile can be used, too. You do not have to use a Tomcat or Jetty to be lightweight!

  • Spring offers features which are not available as JEE standards, such as Spring Batch.

BUT: You can add such a library to a JEE project without problems. You can also add other Spring libraries such as JDBCTemplate or JMSTemplate (which help reducing some boilerplate code) if you want.

  • Spring offers much more flexiblity and power, e.g. aspect-oriented programming is more powerful than JEE interceptors.

BUT: In most projects you do not need this flexibility or power. If you do need it, then use Spring, not JEE – of course!

  • Faster Releases (because it is no standard and only one vendor). The reaction to market requirements is much faster. Some current examples: cloud, mobile, social computing.

BUT: All enterprise projects – of many different clients – which I have seen, are not that flexible. Enterprise applications do not change every month or year. If there is a project, where you can change your version very easily, Spring might be better than JEE under some circumstances. But in most enterprise projects, you cannot simply upgrade from Spring 2.5 to Spring 3.x or from JEE 5 to JEE 6. I wish this would be possible, but low flexibility and politics rule in large companies with thousands of employees.

Conclusion: I will use JEE in most new Enterprise Java Projects

Due to the reasons I explained against Spring in the „BUT“ parts, I will choose JEE in most new Enterprise Java projects. Nevertheless, I will sometimes use a Spring libraries, too (such as Spring Batch). Sometimes, I will even have to use Spring (if I need its flexibility or power), but only then I will choose it. Of course, for existing projects, I will continue using the framework that is used already. I would probably not migrate a Spring 2.5 application to JEE, but I would migrate it to Spring 3.x instead!

So, I have described my reasons why I will use JEE in most new Enterprise Java projects. If I have missed something, or if you have got another opinion (probably many guys have), you can bash me in the comments. I appreciate all „non-flame-war“ discussions…

Reference: Why I will use Java EE instead of Spring in new Enterprise Java Projects in 2012 from our JCG partner Kai Wahner at the Blog about Java EE / SOA / Cloud Computing blog.

Related Whitepaper:

Functional Programming in Java: Harnessing the Power of Java 8 Lambda Expressions

Get ready to program in a whole new way!

Functional Programming in Java will help you quickly get on top of the new, essential Java 8 language features and the functional style that will change and improve your code. This short, targeted book will help you make the paradigm shift from the old imperative way to a less error-prone, more elegant, and concise coding style that’s also a breeze to parallelize. You’ll explore the syntax and semantics of lambda expressions, method and constructor references, and functional interfaces. You’ll design and write applications better using the new standards in Java 8 and the JDK.

Get it Now!  

31 Responses to "Why I will use Java EE instead of Spring in new Enterprise Java Projects in 2012"

  1. Bud says:

    Hi
    My advice is learn both. Forget this blabla battles.
    I would start from showcases on java EE QuickStart and spring showcase on github

    Having more options is always great and this will evolve both frameworks faster.

    Good luck in your studies.

  2. Unni Vemanchery Mana says:

    Hi Kai,

    When we use JEE as far as this post is concerned and since you told, I have a clarification about it. Did you ever experience once you migrate an(spring) application to JEE, better in terms of performance? Just forget it the pros and cons you mentioned in the post. Many of the aspects are related to product lifecycle. Of course, I am not saying here that they are not required, but when you think if you want to deliver any value add to customer, are you only considering these parameters?

  3. Alexander Perdon says:

    You said: “I hope to be neutral”. In my opinion you are not neutral at all. Why do you add this “BUT to all the enlisted Spring advantages and you don’t add a BUT to the so-called JEE advantages. Even the list is far from complete. Next, the CONs are missing.

    Furthermore, the whole JEE stack drives you to a technology oriented approach. While the Spring philosophy will guide you to a more solution oriented approach.

    Just start with a clear and flexible architecture. And then make decisions how to impement your requirements in this architecture. This can either be based on Spring or be based on JEE. But in both cases, the core must be POJOs. With that approach you will even develop your solution in JEE on a Spring way. ;-)

Leave a Reply


6 − one =



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

15,153 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books
Get tutored by the Geeks! JCG Academy is a fact... Join Now
Hello. Add your message here.