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.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

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

  1. Fidel G says:

    When you discussed Advantages, are you talking about advantages of each over the other? I can’t understand why you list testability and Convention over Convention be an advantage of JEE. These has been Spring features for ages already. The way I see it, your goal of being neutral wasn’t successful by the way.

  2. Stan Svec says:

    I recommend do not use acronym JEE according to: http://www.java.com/en/about/javanaming.jsp ;)

  3. chris b says:

    This is not a neutral comparison at all since you list advantages of one above the other (which BTW are wrong like File G said).

    A neutral comparison would have list some criterias and evaluate JEE and Spring on this criteria.

    Standardization : JEE is a standard not Spring (this is not important to me but maybe it is to you)
    Common prinicples : The 2 frameworks have the same base concepts (DI, Annotations, …) and allow to integrate all the boilerplate frameworks (JMS, JPA, …)
    Advanced principles : JEE relies on Interceptor, Spring is all-in for AOP
    Extensibility : both frameworks provide mechanisms but this is rarely needed in both cases and this is hard to do in both cases
    Community : Both projects have a broad community ensuring sustainability and durability
    Documentation : Spring doc is better because it is centralized and up to date
    Time to market : Spring is usually faster bercause it is driven by one vendor only
    Upgrading from vn to vn+1 : both frameworks attempt to be backward compatible but Spring usually do a better job (for ex, you can mostly run spring developped with sping2.0.jar with spring3.0.jar and spring2.0 = JEE1.4 !)

  4. Leon Yip says:

    I will suggest to put in performance comparison to make this article neutral. Nothing beat the number and math speak for itself.

  5. Pedro Costa says:

    IMHO I really don’t see any reason to use JEE at all in any project (unless you are an oracle employee…). The reason is simple, everything you can do in JEE you can also do in Spring, and Spring allows to do much more on top of it…, so why bother?

    • I completely agree with you.This is going to be more political decision rather reading this article Spring vs JEE.I still prefer to go with Spring as mention quite easy to use and lot of features and one of the main feature like is testing which JEE never ever covered it thoroughly.

    • Tim Schwenk says:

      IMHO I really don’t see any reason to use Spring at all in any project (unless you are a VMware employee…).  The reason is simple, everything you can do in Spring you can also do in JEE, and JEE allows you to do much more on top of it…, so why bother?

      • Oliver Gierke says:

        Nice try, but simply reverting the message doesn’t make it true. There’s no support for non-JPA data access in JavaEE, there’s no support for integration or batch type applications. So if you ever face a requirement not approachable with what the standard covers you’re screwed. There’s tons of undocumented implications when using the JavaEE annotations (@Singleton:twitter  effectively serializing *all* method calls to the object), a crippled DI model (constructor injection anyone?), yadda yadda yadda…

        But even if we stick with your statement and agree on JavaEE being on par with Spring: where are the features JavaEE provides, which Spring does not? I’ve asked this question in my more verbose post above but so far haven’t got an answer at all. I’d even argue it’s not the purpose of a standard to come up with features no competing platform has yet – it’s a standard after all, so that’s perfectly fine. That’s why I did not include that fact in my arguments list. But it’s funny still actually tries to use this as argument. Anyway, I am happy to here where the JavaEE world offers more features than Spring does :).

        • whippa says:

          I’m in the Spring camp myself but many companies purchase expensive application servers, databases, hardware for the comfort of dedicated consulting/vendor support services and (being slightly facetious) to be able to sue someone if there’s a resulting problem in the technology. In this situation with the app server having been decided on this basis (as well as meeting performance, availability requirements) and with Tomcat not in the running, the resulting web app software architecture is founded on JEE not Spring despite IMO Spring being the more powerful, agile and flexible of the two frameworks. 

          • Kai Waehner says:

            “Spring being the more powerful, agile and flexible of the two frameworks.”

            I absolutely agree!

            The question is if this is an advantage all the time. In most of our projects, (unfortunately) this is a disadvantage because the organization is not ready for too much power, flexibility and agile development. I do not say that I like this, but that is reality in many huge (non-IT) enterprises.

        • Miljenko Norsic says:

          Talking about features, Spring is definitive winner in terms of testability,
          deployment on different app servers, feature list etc. But I’m not confortable
          with the fact that the whole DI is on application level. 
          For example, if I have
          to use EJB, I have to initiate a separate Spring container per EJB, and that’s
          not effective at all vand it makes my app very memory-consuming (yes, I know, I
          can make a shared Spring container for all the beans, but my suspicion is that
          it uses thread-local storage and that is IMHO evil in JEE world). JPA per se is not such an evil (albeit you are stuck with it, but can also change provider easily). Why bother with non-JPA data access at all?

          To me, Spring is more developer-centric, more testable and more feature rich. But it comes with a cost of a large application footprint and too many features involved. I doubt that most of use everything from its bag of tricks…

          • Kai Waehner says:

             “To me, Spring is more developer-centric, more testable and more feature
            rich. But it comes with a cost of a large application footprint and too
            many features involved. I doubt that most of use everything from its bag
            of tricks…”

            This is exactly my experience. And this is why I prefer Java EE in most use cases. As mentioned in the article: “Convention over Configuration is everywhere [in Java EE 6] instead of explicit (I know
            that some people will disagree that this is an advantage).”

            So, @olivergierke:disqus
            I absolute agree to most of your comments! I cannot tell you any features of Java EE that you cannot solve with Spring. This is why I wrote that you can realize most use cases with both (and some stuff such as Batch is not available in Java EE, but in Spring).

            Though, as I have described, I do not need the most up-to-date API, portability or several complex Spring features in most of our projects. I need a stable and easy to use programming model, which can be used also by newcomers easily. Our application often do not upgrade to a newer version.

            I do NOT say that I do not want to upgrade! Often, this is political, but most huge projects I know are not upgraded to a new version, if there is no real benefit for business (and usually, you cannot show any benefits for business by upgrading from Java EE X to Y or from Spring X to Y). In the end, I want to create business applications easily, and IMO Java EE 6 (not 4 and not 5) beats Spring. That is why I would prefer Java EE 6 in most use cases.

            Sum up: I cannot tell you any features that Java EE offers and Spring does not. Though, I never tried to because Java EE is sufficient for of our projects. If not, I am happy to use Spring without any discussion instead of Java EE…

            Best regards,
            Kai Wähner (Twitter: @KaiWaehner)

          • Oliver Gierke says:

            “I need a stable and easy to use programming model, which can be used also by newcomers easily.”

            Would you mind outlining how Spring fails at that?

            “In the end, I want to create business applications easily, and IMO Java EE 6 (not 4 and not 5) beats Spring.”

            That’s highly vague and depends on what your business application looks like. So I’d argue this is a wrong statement in more cases than it isn’t (because neither you nor me know what a business application looks like for others). So I’d argue that for such bold statements the more flexible technology will make the point due to it’s nature. If you go ahead saying: I have requirements X, Y, Z and JavaEE just satisfies them – why should you do anything but JavaEE? I am completely with you. But I’d still argue that if you’re caught in chains and don’t move you certainly don’t feel the pain. Spring is incredibly simple for simple use cases (such as JavaEE is) but enables you to do more complex things if necessary (which JavaEE let’s you hit the wall at).

            I just think that claiming the death of the others technology because of the own perception (just as Bill Burke just did in his recent blog post http://bill.burkecentral.com/2012/03/13/java-ee-wins-over-spring/) is completely off the path as there’s always more unknowns than knowns and you cannot tell people: I don’t need it, the world doesn’t need it…

  6. mohamed boufnichel says:

    Hello,

    I agree with leon the math speak should appear not the feelings one :)

  7. Nico Van Belle says:

    The way I see it, JEE only has only one advantage over Spring and it’s a pure theoretical one; it’s a standard.
    Some companies care, others do not.
    For the rest, I agree with chris b. His comparison is more neutral than yours. sorry
    I do agree when you say that JEE6 has come a long way and that nowadays, it’s actually usable

  8. MateuszBukowicz says:

    Nice article. I sometimes hear people saying that there are no more projects starting with JEE anymore. I think this is a common misconception caused by J2EE (1.4), like you mentioned in the beginning.

  9. Javier Beneito Barquero says:

    I’m going to use Spring in my projects for a long time because it encourages you to good programming (dependency injection, use of interfaces, separate of concerns, unit testing…) and it allows you to locally test your business logic.

    Besides, the new feature of profiling allows you to develope in one environment (or two if you want to) and easyly deploy to any application server.

    However, is still has a big con: if there is any library collision, you will have to work a lot to solve the related issues.

    And that’s true, some new technologies are not functional enough (like Spring Integration and Spring Batch) Nonetheless, the same could happen to the equivalent offered by the vendors, and they are very (very, very, very) expensive

  10. Oliver Gierke says:

    It’s great that you add the “BUT” on the Spring side but forgot to do on the JavaEE side. Let me help you out a little bit on that one:

    Portability (because it’s a standard) – it’s 2012 and I am puzzled this myth is still around. Have you ever tried to port a non-trivial application from one application server to another? The different JPA providers alone make this close to impossible. That’s why I think coding you app against JPA is fine but requires bundling the persistence provider with it to be portable (in case that actually matters to you).

    Up-to-date-ness – upgrading to a new JavaEE version is similarly without efforts as porting is. JavaEE 6 is from the end of 2009, so almost 1,5 years ago. Remember it’s a standard so you get a programming model that retrofits programming problems and approaches from back then. It solves yesterdays problems by definition, period. Now as the supporting server space has evolved over the years on might argue we could start new apps on JavaEE. But do you really want to argue to use a 1,5 year old programming model for a new app which might have to live for the next 5 years? It’s nothing really wrong with JavaEE but an intrinsic trait of standards.

    Upgrade path – now assume you really decide to go down that route. You deploy your JavaEE 6 app to an app server of choice. 2 years go by and a new version comes out providing features you might wanna use. Now you’re screwed in two ways: first it takes – as we just discovered – app server vendors quite some time to get up to the new spec. So even if the new version of the standard is release, it’s not really usable in production (unless you want to go Glassfish). Plus you have to convince your operations team that it’s worth to spend bucks for the new version of the app server of choice. But probably not once it’s released but after the first or second bugfix.

    Off-the-path-requirements – JavaEE is quite narrow minded in terms of e.g. supported persistence technologies. For the JavaEE world everything that exists is JPA. You might be able to go back to JDBC but I recommend to take a look at the spec how your code will then look like (feels a bit like back in 2000). So you start your application development on JavaEE and better pray you will never face a requirement that might introduce something outside it’s scope. Of course you can then fall back to libraries but off goes consistency then.

    Quite the contrary with Spring: decouple the programming model from the server infrastructure, that is what it’s all about. This will allow you to port apps from one infrastructure to the other, even use up to date JavaEE APIs with legacy servers (still stuck with Tomcat5 but need to run JPA 2 – no problem at all). Updates are usually a drop-in replacement technically, but of course have to be well organized (I’d argue it’s still less hassle than with a JavaEE programming model). Plus a rich eco-system of projects you can either completely ignore if you want to but pick and choose components with the very same programming model in case need be.

    So to me your pro-JavaEE list just reads like a “Me, too!” list (as it to some degree has to be due to the nature of a standard, which is completely fine). And if you argue: “JavaEE is all I will ever need” it’s fine (it might turn out this will be your “640k for everyone” though). What I’d be interested in though is, what do you think are the crucial points where JavaEE exceeds Spring’s capabilities, the points where it provides value add *over* Spring? I mean, the “it’s a standard” aside.

  11. Václav Matouch says:

    Have you considered an alternative like the Play Framework?

  12. Faisal Aziz says:

    I would think about going pure JEE only once out of container testing is as seamless as it is with Spring.

  13. Marcos Eliziario says:

    Man. Are you still on this band wagon. I was once a JUG leader, been programming in Java for the some 15 years, and for me, it is clearly a dead horse.
    JEE and Spring are both an hindrance to good development, they are full of anti-patterns. And the first anti-pattern is calling something “Enterprise App”. More and more “features”, and hordes of programmers that are no much than mere push buttons. And the result? The result you can in any company, slow, dumb applications that are hard to use, that require full time maintenance.
    You don’t need more frameworks, you don’t need shitty,half-assed JCP “standards”. You need better programmings, you need better and more expressive languages. Startups all around the world are running circles around enterprise development shops, because they are faster to market, their applications have less bugs and are faster and more scalable. Look around and you’ll see. In the time it takes for you to develop a new module, painfully integrate, and test it to deploy, facebook has deployed a staggering number of releases, rolling out them in thousands in servers, for half a billion users. And why? because they are not wasting time with JSRs, with bloated app servers, with stupid tools like eclipse, with untestable things JSF. Sone our later, one facebook/twitter-using CEO is going to notice this, and ask, why can’t those bastards downstairs deliver with the same smoothness, speed and precision as those guys? and the answer, folks, is largerly your blind following of this piece of shit called JEE.

  14. Bernard Ligny says:

    For those who are interested, I wrote a +/- similar article a few months ago on JCG, with a concrete comparison of both technologies:
    http://www.javacodegeeks.com/2011/11/from-spring-to-java-ee-6.html

  15. Mehdi Heidarzadeh says:

    With Spring you can just get support of VMware’s tc server.
    BUT with JEE 6 you have more options to choose, Glassfish, jBoss, Resing, Weblogic and many other application servers.

  16. Rany says:

    Both doesn’t seem to have an advantage over each other aside from the fact that Java EE 6 is a standard. The only problem I see with Spring is that it is redundant.
    Spring is the new Struts and like Struts, it is being deployed to many production servers already and its seems hard to migrate. My point is, its already a legacy framework, it maybe deployed to lots production servers already but so as Struts and Cobol.
    For new projects, just use java ee 6 and you will be giving yourself a favor.

  17. Mario Giammarco says:

    It is very simple: my customers have only tomcat, want to use only tomcat, period. J2ee force you to you jboss or (my God)  glassfish, or some other thing that is not Tomcat. Spring not.

  18. unni mana says:

    When we talk about JEE , immediately we tend to think about those days we had faced when J2EE/EJB combination was there.Developing a full blown J2EE compliant application with EJB was very tedious process. No doubt about that.Moreover, selecting an EJB component (to be or not to be) was little bit scary as well.In fact there was a lot of learning curve for both experienced and entry professionals alike.So to save , Spring came. It was because of its easiness and less learning curve, there were many existing applications converted to Spring.Spring introduced the concept of attribute driven programming.Later on many frameworks followed the same suit.JEE, I think is the last one which completely ported many of the existing features of Spring.So in a nutshell, those who had very tough time with J2EE, Spring was the breeze because of its easiness and less complexity.May be JEE would have matured enough, but the kind of features, support , community and training I think Spring stands ahead of JEE at this point of time.Not sure about in future.

  19. - Spring’s Exception handling is excellent and 99 times out of 100 I will get a clear message when something goes wrong. The same cannot be said of other vendors JEE implementations.

    – I am not 100% convinced that each JEE6 app server has 100% same behavior with JEE6 e.g. CDI. There are also significant amount of bugs being found in App Server’s JEE implementations e.g. look at fix list for WAS 8

    – Spring has solved many of the problems the real world throws at it, where JEE hasn’t. Yes this means it’s bigger, but something probably already exists to solve your issue. JEE6 I feel like I am facing these issues for the first time. For example on WebSphere I wanted to change the Connection’s txn isolation level – 30 minutes later my problem was solved by http://static.springsource.org/spring/docs/3.0.x/api/org/springframework/jdbc/datasource/WebSphereDataSourceAdapter.html

    – Generally I feel if I need to do something complex I can do that with Spring. I am not sure JEE gives me the same flexibility.
    – The JPA implementations on different app servers is a mess. OpenJPA or Hibernate – the behaviour is not the same, even though the JPA API is

    For simple to medium complexity apps I think JEE6 is the way forward – but for very large and complex, enterprise apps I would stick with Spring.

  20. Paul Okeke says:

    I’m currently new to all this, seems like you all here are vast and professional in this aspect, I really don’t know which to learn! Between spring and javaEE6, a lot of controversies basically every where one the internet. People keeping saying spring, some other set of people say javaEE! Whichever, all I need is an advice on a path to follow or the next step! I’m currently on jsp and jsf, buh I intend advancing my knowledge! And also, I have doubts most times due to the expensive nature of hosting a java website, it kills my morale most times..pls I need an advice

Leave a Reply


7 − = six



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
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.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close