Java EE vs Spring. Or: What is a standard?


It is always entertaining to read articles with a “Java EE vs Spring” topic, as the discussions are normally very emotional and quite funny. So I always told my self: “Don’t write another Java EE vs Spring article” – BUT: Here it is.

The reason is that I read an article in the current issue of German Java Magazin (4.2011). In the series “EnterpriseTales” the authors give this reommendation:

Generally we recommend to use the standard in new projects, if there are no reasons to not chose the standard.

With standard the authors mean “Java EE 6”, as the article is about a comparison of Java EE 6’s CDI and Spring.

For me one question arised: Is Java EE 6 really the standard for Java Enterprise development? What is a standard? So I asked Wikipedia:

technical standard is an established norm or requirement about technical systems. It is usually a formal document that establishes uniform engineering or technical criteria, methods, processes and practices. In contrast, a custom, convention, company product, corporate standard, etc. which becomes generally accepted and dominant is often called a de facto standard.

Two really interesting points: A standard is an established norm and something generally accepted and dominant is a de facto standard.

I am developing Java since 1996 and since 1999 also with the Java Enterprise Edition. Some parts of Java EE I would call “established” based on my experience. For example the Java Servlet Specification. Servlets have basically not changed since 1999 and I cannot remember that we had major migration efforts in the last decade. The WAR archive, web.xml and the major interfaces have been stable and the servlet specification has carefully improved over the years. (e.g. servlet filters) Almost all major web frameworks are based on the Servlet API and I would say that servlets are one of the reasons why Java has been a big success on the server side. (compare it to CGI and you know what I mean) Also the support by major vendors was very good. There are lots of servlet conatiners/application servers out there, which are stable and used in thousands of production environments (Tomcat, Jetty, JBoss, Weblogic, WebSphere, …).

Let’s get back to Java EE – which is more than servlets. There are many parts of this “standard” where my experience was not so positive. Let’s look at the Enterprise JavaBeans standard, which in my point of view is a desaster. I used  EJB 1.0 in 1999 as the promise was to have a standard for Enterprise component development with container managed security, transaction, persistence etc. The standard didn’t last for long. With EJB 1.1. you had to do a migration of your existing code. The same with EJB 2.0 which was a whole new redesign of the standard. And now EJB 3.x which has nothing to do with former EJB standards (except the naming) and copied the POJO model from established frameworks like Spring, but with limited support for dependency injection in other parts of Java EE. This is the reason why Java EE 6 looked at JBoss Seam and implemented CDI. If you look at JPA (part of EJB), it looks like a limited Hibernate clone – nothing to do with former entity bean standards (by the way: Do you remember the JDO standard? Where is it today?) What about application server support? It took years to have EJB3 support in major application servers (like WebSphere) and I don’t know application server in production that fully support Java EE 6. What about investments in this standard? Trainings for the developers, tons of lines of code around EJB 1.x-2.x, …

For me EJB is an example that Java EE has nothing to do with a standard – because it is not “established”. For years the Java EE standard is runnning after the innovation of defacto standards – like Hibernate or EclipseLink. Or Spring, or GWT, or …

The new standard is often just a bad copy of the original. Look at JPA: A political API that is reduced to a minimum set of functionality. Was JPA 1.0 useable? I don’t think so – can you really use a O/R mapper without a second level cache? Why should I use JPA in favor to Hibernate which is stable for years, has much more functionality and I can use it in any application server/servlet engine? Answer: There is no reason.

JSF is another example. Build to provide software vendors to sell component libraries and tools, it never worked as expected (I did a JSF 1.0 project and still feel the pain, when I remember it). Facelets tried to overcome the issues and finally it was taken over as the standard. Now you have a “1.0 framework” and we are already years in the “2.0 world”. Look at frameworks like GWT or Vaadin and you know what I mean. If you use AJAX and JSF – please be careful with the memory – JSF was not designed for such use cases.

CDI (Java EE 6) vs Spring is a similar discussion for me. Spring has a stable IOC implementation for more than 5 years. The investment in Spring (training, etc.) is still worth the money and I cannot remember major migrations because Spring never fundamentally changed it’s design. Each release is a consequent and innovative improvement (annotation, AspectJ, …) – this is the reason why I would call Spring a defacto standard. CDI/Java EE 6 may have a similar (or in some parts even better) feature set, but this doesn’t make it a standard for me, especially if I look in the past. Who guarantees that Java EE 7 will not be the next migration?

So let’s get back to the initial statement of the Java Magazin article:

Generally we recommend to use the standard in new projects, if there are no reasons to not chose the standard.

I can only support the statement, but Java EE 6 is not a standard! Because it is not established! Parts of it are established for sure (like Servlet API), but other parts like EJB 3.x and CDI will have to prove there stability in the future. Therefore I would say that you should carefully evaluate what is a (defacto) standard you should chose. Spring or Hibernate are defacto standards in my point of view, as they are used in thousands of projects for years. Adam Bien (a popular speaker and freelancer working with Java EE 6) says in the same Java Magazin (page 52 – translated by the author of this blog):

CDI is not ready yet.

CDI is missing critical features like transactions or asynchronous processing which are available in EJB 3.1. You could reimplement them in CDI, but a minimalistic solution would be a combination of EJB 3.1 with CDI in Java EE 6 (se for example …”

CDI could take off with  Java EE 7. It could provide the EJB 3.1 exclusive features to the public.

Ok – Java EE 7. The JSR says: final release in Q3 2012. As we know from Java 7 this means: “maybe end of 2013 with major application server supporting it in 2015”. So I will use the defacto standards like Spring, Hibernate or GWT and will observe the official standard. If it someday will be stable and established I will consider switching to it – but I could imagine that Spring and Co. will have moved again two steps ahead…


  • Mirko Novakovic

    16. March 2011 von Mirko Novakovic

    Hi Adam,

    here it is… 🙂


  • Grzegorz Grzybek

    16. March 2011 von Grzegorz Grzybek

    Great post!

    That’s exactly what I’ve tried to state in my comments to “JavaEE vs. Spring” discussions. Servlets API is standard, JMS is standard and attempts to use other JavaEE “standards” are more of political origin (e.g. here you [the develoeprs] have shiny new WebSphere 6, we’ve paid a lot, so make some use of it without packing spring-*.jar into WEB-INF lib).

    When talking about 3-sec deployment time and “guest the number” showcases, JavaEE6 seems brilliant, but when you go outside your java-rock-star … rock into the real (enterprise) world, you’ll see that some other things matter. E.g. the fact that the application I’ve been involved in used spring since 1.0.2 version. Now it uses spring 3.0.5 with one change in one *.properties file (

    class -> (class)

    ). Most problems during migration from WebSphere 5 (in words: five) to WebSphere 6 (in words: six) were with JSP/taglibs – they just didn’t work. We’ve got rid of: MDBs, EJBs, container based security (replaced with Spring-Security – two LDAPs involved in user’s authentication – JavaEE says nothing about it). Now we have WAR which runs not only on WebSphere 6, but also on Tomcat, Jetty and embedded Jetty in integration tests run by Jenkins.

    As you said – JavaEE 7 will be shipped in 2012. It will have resurrected JSR109. But see what Spring 3.1 has already for us (env profiles, cache abstraction, …)

    Grzegorz Grzybek

  • Calin Martinconi

    16. March 2011 von Calin Martinconi

    Excellent post.

  • John

    Poeple when they hear of JEE6 and EJBs they all are still stuck comparing spring with EJB2.0. The time is to move on rather than getting stuck in that mindset. There is no question that Java Enterprise included the concept of Dependency Injection introduced by Martin Fowler (Spring being one of the popular frameworks implementing it). As you said standards are driven by industry’s general practices and recommendations. And neither JEE or nor Spring is are evil.The moment we start tarnishing each other in process we hamper the progress of them. And focus the energy in advancement of them.

  • Antoine Sabot-Durand

    17. March 2011 von Antoine Sabot-Durand

    I’m not sure to understand. Spring is the de facto standard, so Java EE 6 is useless and nobody should care ?
    Spring is a great framework but even if it’s OSS and has free edition it is a proprietary framework. CDI has already 3 implementations… It’s better than spring which has only one.

    I won’t say Spring Source is evil but I don’t like their politic. They could have done what was needed to standardize their framework but they choose to keep it proprietary. What if JBoss had choose to do the same with Hibernate 4 years ago to concurrence JPA ? Do you think our work would be easier today ?

    Today Java EE is at last usable and I think that every people who wrote “Java EE or J2EE” should care and learn about it. It’s not about switching to Java EE, I agree it’s a bit early, but it’s about caring about a good standard that brings a strong alternative to Spring.

  • Antonio Goncalves

    Hi Mirko, great post… but a few comments ;o)

    First of all, there is a very important missing point in Wikipedia’s definition of a standard : exchange. When I tell you that I’m 1.78m tall, you know what I mean… and you know what I mean worldwide (I can even translate it to inches, feet…). This standard allows us to communicate and understand each other.

    EJBs are a disaster because, as you say, it didn’t gain a big success on open source fwk or editors (except for IBM/Websphere, BEA/Weblogic or RedHat/JBoss). But that’s because, technically, there were quite difficult to develop with and difficult to implement. When you say that EJBs have changed completely, it’s not exactly true, in fact I would say that EJBs 3.x == EJBs 1.x. They both use the same good old mechanisms behind (proxies, stubs, interceptors…) except that the development API has completely changed. So, for a developer’s point of view, it’s new, but behind the scene, it’s the same (methods of a @Remote interface don’t have to explicitely throw an RMIException… but RMI is RMI, so there is an RMIException somewhere, except the developer doesn’t have to deal with it). But I agree, technologies/frameworks should not be standardised too soon. EJBs were #fail

    JPA was not a political compromise : it was a complex spec written from scratch (the expert group didn’t take anything from the Entity Beans, so they had less than 3 years to do something brand new in the EE space). That’s why it was inferior to Hibernate (but JPA 2.0 has filled this gap).

    As you mentioned, one of the failure of Java EE is due to application servers. When you think Websphere, Weblogic… you think monolitic. Now the world is changing. You can use Java EE 6 as a jigsaw puzzle and only take a few bits of it.

    But there is something else I’d like to point out. To create a standard you need plenty of things (mature technology, agreement of other companies, compromises, failures…), and one of these things is courage (courage to expose part of your business to the world who can copy it… and improve it). I’m sure you would agree that batch processing has been around for more than 50 years, so it is mature. But we still don’t have a standard, we still don’t know how to develop reliable/distributed batch processes in a standard way. I use Spring Batch, which is a very nice stack. Do you think SpringSource (i.e VMWare) will have the courage to standardise something that will take part of their “revenue” ? You talk a lot about Hibernate & Spring. JBoss had the courage to give most pf its knowledge to the JPA 1.0 expert group. Sorry, but SpringSource didn’t do the same in the EJB expert group. And history would have been different if EJBs had more of Spring (we would have renamed the EJB spec to something different maybe, just like JPA did with Entity Beans).

    One rule of thumb is : use a standard as much as you can so people can understand you, leave the standards when it slows you down. The example you give with JPA is the perfect one : use Hibernate as the implementation, use standard features when possible, and use Hibernate specific features when missing (BTW, JPA 2.0 has a second level cache now). In my day to day work I use Spring and as many Java EE 6 features as I can (JPA 2.0, Bean Validation 1.0, JSF 2.0…). But when I need more, I use more (Hibernate specific stuff, Spring WebFlow on top of JSF, Spring Batch). So it’s not one or the other, it’s a bit of everything.

    Stick to the standard when you can, leave the standards when you need.

  • Antoine Sabot-Durand

    17. March 2011 von Antoine Sabot-Durand

    I twitted Adam Bien about his statement on CDI and it seems he changed his mind :

  • Adam Bien

    Hi Mirko,

    your cited me wrong:

    Sorry, but I never said that: “CDI is not ready yet. […] CDI could take off with Java EE 7. […]”. You should cite the context as well. Please correct that.

    I said (and even wrote articles about that): in Java EE 6, CDI cannot be used without EJB 3.1 conveniently. In Java EE 7 it will (probably) get the most interesting EJB 3.2 aspects and will really take off then.
    See also my posts about this topic:
    <a href=""CDI With Or Without EJB 3.1

    CDI With Or Without EJB 3.1

    adam bien

  • Antoine Sabot-Durand

    17. March 2011 von Antoine Sabot-Durand

    I’m not joking. And I don’t consider that Java EE is Oracle property. A lot of company and individuals worked on Java EE and it’s rather insulting to say that they obeyed to Oracle.

    So yes I think that Java EE is more Open than Spring : you only have to count the number of implementation of each specification.

    An by the way if you go this way I have no preference between VMware and Oracle : I don’t trust them both.

  • Adam Bien


    My whole statement is: “In CDI fehlen aber noch entscheidende Aspekte wie Transaktionalität oder asynchrone Verarbeitung welche im EJB 3.1 vorhanden sind. Man könnte zwar alles in CDI nachbauen, eine minimalistische Lösung wäre jedoch die Kombination von EJB 3.1 mit CDI in Java EE 6 (siehe z.B. …”

    So richtig abheben könnte CDI mit Java EE 7. Es könnten hier die “exklusiven” EJB 3.1 Aspekte der Allgemeinheit zur Verfügung gestellt werden

    These are my statements. You used a pieces of the cite and created your own…

    AND: I’m not an Java EE 6 evangelist, rather than a freelancer working with Java EE 6. Because I use it – I talk about it. I also like it 🙂

    You took two pieces from JavaMagazin and created your own statement. Its o.k. but it is not my statement….

    Now: turn off your android and care about your baby. Otherwise some system exceptions can happen.


  • Antoine Sabot-Durand

    17. March 2011 von Antoine Sabot-Durand

    Good luck. The third is not always the easiest ;-).

  • Mirko Novakovic

    2. May 2011 von Mirko Novakovic

    Hi Strub,

    it’s good the hear about your positive experience with Java EE 6.

    You developed an application for a university and I think that it is quite ok if you chose to be an early adopter of a new framework like OWB – especially if you are one of the core developers.

    But my point was that OWB, Weld etc. are “1.0” implementation – even if the version number of Java EE tells that it is a “6.0” implementation. And just because it is a “standard”, I have problems as an software architect to claim that you should prefer this standard in any situation where it fits into your requirements (this was the initial statement of my article).

    It is also interesting that you are not using the “standard” as a “standard” but more as a framework (which fits very well into my statement about not standardizing every framework around in the open source world with more than 1.000 users). You are using Tomcat which is not a Java EE 6 application server and deploy parts of the Java EE 6 “standard” as part of you application WAR (or you put it somewhere else on the classpath). No problem with that (and it seems to work very good for you) just wanted to point that out.

    Anyway, I am not against Java EE 6 or claim that the Java EE 6 standard is bad – just wanted to say: Chose the right tools for your problem 🙂

    Interesting side note: I am currently working on my “Elastic Java” presentation that I will have on Wednesday at JAX 2011, where I take a look at different Cloud platforms (PAAS) for Java. I chose Google AppEngine, Amazon BeanStalk, and Cloud Foundry as I think that they are the leading Java PAAS offerings around. Without any rating it was interesting to see that no of these platforms chose Java EE 6 as it’s runtime – even if they all utilize some Java EE standards like JPA or Servlets. At least 3 of these 4 platforms chose Tomcat as there server (as you do) and also 3 of these platforms seem to push Spring as there programming model.

    Has anybody experience with Java EE 6 Cloud PAAS offerings?

  • Reza Rahman

    Your suggestion that Java EE is not open is very misguided and unfortunate.

    As an independent working in the JCP I have found it to be effective, collaborative and very open. It is sad that companies like SpringSource/VMWare have such poor participation in the JCP.

    One of the core value propositions of a standard is that it should promote vendor/implementation neutrality – Spring makes you do the exact opposite.

  • Mirko Novakovic

    26. May 2011 von Mirko Novakovic

    Hi Reza,

    putting aside any emotions – where did I say that Java EE or the JCP is not open?


  • Reza Rahman


    Spare me the melodrama, please — there are absolutely no emotions involved on my part – just facts the way I see them.

    You seem to have a rather short memory frankly. A few posts ago you suggested that SpringSource is just as open as the JCP because the JCP is supposedly “led” by Oracle. Nothing could be farther from the truth. If you actually paid any real attention to a JSR you’d know that they are highly collaborative processes in which few decisions are made unilaterally by Oracle and few ideas originate from them. In fact, Oracle/Sun tries it’s best to have other companies lead JSRs — Red Hat leading CDI is a great example.

    A vast majority of the Spring code-base on the other hand is tightly controlled by SpringSource committers. Don’t believe it? Try suggesting that Spring should implement CDI or EJB 3. You’ll find out exactly how open SpringSource supposedly is…


  • Reza Rahman

    Here is an interesting analysis on how “open source” SpringSource is, let alone the issues of openness in general and vendor neutrality:


  • Mirko Novakovic

    27. May 2011 von Mirko Novakovic

    Hi Reza,

    we have people *leading* JSRs in our company, not only participating, so I really believe in the value of JSRs and in the Java EE standard. I’ve never talked about openess (which is a total different story). If openess would be the No. 1 driver for the decision which framework/software to chose than no one would use Oracle DB, SAP, etc. – and no one would use frameworks like GWT, Guice, Hibernate, Wicket, because they are not open in your terms, right? I believe you would suggest to use JSF for a high scale, rich internet application and you would help the client solve the problems with there big sessions. By the way if no one would have used “non open” frameworks like Hibernate, Seam, Spring, etc. – I strongly believe that standards like EJB3 or CDI would never have been defined.

    I would like to ask you what are your answers to these questions – maybe that makes my point clear to you:

    – Would it have been a good decision for clients to select “Enterprise Java Beans 1.0” as there component framework back in 1999, as it was *the* industry standard for Java EE components?

    – Would you suggest to use any “1.0” framework/standard in a business critical project if there are rock solid alternatives with similar feature set, just because the 1.0 framework is a standard?

    – Would you say that you are not utilize Java EE if you are not using CDI, but many of the other JSRs that are under the Java EE umbrella? (there are more than 30 JSRs and CDI is only one of them – some of them very mature like Servlet 3.0 or JCA 1.5 – some of them new in Java EE 6 like CDI 1.0) – see for more information about Java EE 6.

  • Mirko Novakovic

    27. May 2011 von Mirko Novakovic

    Reza, just adding one more question:

    Would you suggest using Java ME for mobile Apps of your clients, because iOS and Android are not open (which is for sure true for iOS) because Java ME is the industry standard for mobile Apps driven by an open community of industry leaders? (Or like the Java ME website says: Java ME is a state-of-the-art toolbox for developing mobile applications.)

  • Mirko Novakovic

    27. May 2011 von Mirko Novakovic

    Interesting article from Niklas about the same topic and comments to my article:

  • Reza Rahman

    Sorry, but you are making deliberate distortions (and apparently not just in my case but Adam’s and the original article author’s too). What you are doing is called a straw-man argument (and you have more than one of those as I’ll point out). It’s a well-known logical fallacy – look it up. In fact, your entire blog post and comments seem to be a series of distortions (makes me really wonder about your underlying motivations). Here is why:

    * From what I’ve seen so far, no one has suggested that a standard should be adopted just because it is a standard. Even the author you quoted suggests standards should be considered first (because they are open and vendor neutral) unless there is a good reason not to do so (i.e. the standard solution is not right for the problem).

    * I didn’t say open source in general is not open (although I really don’t think SpringSource is). I said it’s not a substitute to standardization. If it’s a viable choice, it’s best to choose an open-source, standards based product.

    * A product version means nothing to me. I’ve successfully used many alpha/beta tools that kick a$$ compared to so-called “mature” products. Only a non-technical imbecile would judge product quality on version numbers — the kind of technologists I personally despise with a passion :-).

    * No one so far has suggested you are not using Java EE if you are not using CDI. Only you are. That being said, there’s no denying someone not using CDI is probably not taking full advantage of Java EE since CDI is central to Java EE.

    The post you linked to mentioning your article is equally full of hand-waving and I’ve commented on why that is (including the bull$h1t about CDI “immaturity”).

  • Mirko Novakovic

    27. May 2011 von Mirko Novakovic

    Hi Reza,

    never heard about “straw-man argument” before, but I like it.

    If I really understood what a “straw-man argument” is, than your last post is full of it 😉


  • Reza Rahman

    Really? Care to explain how? It would be good practice to get that “straw man argument” concept down since it’s new to you :-).

  • Mirko Novakovic

    27. May 2011 von Mirko Novakovic

    Of course I will 🙂

    Here is your statement:

    “No one so far has suggested you are not using Java EE if you are not using CDI. Only you are.”

    I never said this, I said “there are more than 30 JSRs and CDI is only one of them” and that I really like most of the Java EE standards like Servlet, JMS, etc.

    If you don’t understand why this is a “straw-man argument” read this: – it really helped me 😉

  • Reza Rahman

    Man – you really do have a short term memory or a very poor grasp of the English language or both :-).

    Here is what you said a few posts ago – “Would you say that you are not utilize (sic. utilizing) Java EE if you are not using CDI”. That implies that you either think I believe this or some other (unstated) person does. If you don’t believe that is someone’s stated or unstated position, why bother asking the question at all?

    Wanna try again :-)?

  • Mirko Novakovic

    28. May 2011 von Mirko Novakovic

    What I said is: “Would you say that you are not utilize Java EE if you are not using CDI, but many of the other JSRs that are under the Java EE umbrella? (there are more than 30 JSRs and CDI is only one of them – some of them very mature like Servlet 3.0 or JCA 1.5 – some of them new in Java EE 6 like CDI 1.0)”

    I would say that 99 of 100 (if one of the 100 is you) would understand that I wanted to say that I think that CDI is only 1 of more than 30 CDIs and if you don’t use it than you still use Java (which I also stated in my whole text and comments).

    Reza, if you are ready to discuss on a fact level, I am ready to go on with this discussion. Your last statements where you try to say I am person with low memory, poor grasp of English and a non-technical imbecile, show me that you either want to provoke me (but in a very non intelligent way) or you have some other deep problems with Spring or what ever, so that you are not able to discuss on a non emotional level.

    See the Iceberg model and theories of Sigmund Freud to understand the psychological models behind your problems:

  • Reza Rahman

    Nope — I just find your entire so-called “analysis” that utterly mindless/offensive honestly — starting with your obvious confusion about the differences between a de facto standard, technical standard and open standard.

    Do read the Wikipedia entry you quoted carefully — starting with closely examining the connector “in contrast” in the sentence you quoted. Spring is not a technical standard. That means it is not an open standard either (go look it up). At best it can be a de facto standard — and even that is questionable since it is mostly self proclaimed. De facto standards do not guarantee openness unless they go through an actual standardization process to become an open standard. Adobe PDF is a great example. It started as a de facto standard and actually became an open standard in 1995 via the ISO. Java EE is technical standard as well as an open standard, “in contrast” :-).

    You seem be to be similarly confused about what “established” means — a technical standard need not be well-used or widely adopted at all — it just needs to be finalized/defined. Look at the standards listings for ISO, IEEE or W3C and you’ll find many obscure technical standards that never gained much wide acceptance but are standards nonetheless. If you are quibbling about what a standard is, at least get your terms right first! At best you can argue that Java EE is a flawed standard — that’s it :-).

    Here is a bit of Yankee pragmatism for you — I don’t give a hoot about EJB 1, EJB 2 and J2EE. It’s about as relevant to me as who fired the first shot in the civil war :-). What I care about is how Java EE 6 stacks up to Spring 3 and what I should adopt going forward :-).

    From that perspective, here is how I see things:

    * Spring 3 – complex, bloated, legacy-heavy, hardly innovative any more and bound to a single vendor — in summary: sucks.
    * Java EE 6 – simple, modern, streamlined, innovative and open — in summary: rocks.
    * More a$$ kicking features on the way with Forge, Arquillian, Seam 3, Apache MyFaces CODI, Java EE 7 and many more from the Java EE ecosystem.

    That’s why people like me, Adam and Arun have capacity crowds coming to learn about Java EE 6, CDI, Seam etc :-).

    Want a real technical analysis? I have one coming demonstrating the points above in detail — inspired by none other than this “analysis” of yours :-). I’ll forward to chatting with you about it soon…

    Do let your “partners” at SpringSource know about it too :-).


  • Mirko Novakovic

    28. May 2011 von Mirko Novakovic

    Hi Reza,

    thank you that you return to a technical discussion.

    What you didn’t understand is that I didn’t say that Spring is an better IoC container/approach than CDI from a technical perspective. I also never said that Spring is a open standard or technical standard – I said it is a defacto standard which I said based on my experience that many of our customers are using it very successfully.

    I liked Seam from the beginning so do I like CDI and I am happy that guys like you or Adam are doing a great job to make Java EE more popular (I have never seen you in action but Adam is an amazing presenter and I always enjoy seeing him on a stage). I also think that Java EE 6 has gone a big step into the right direction and that Spring and Java EE 6 are not very different if you compare them where it makes sense. (I think in many cases it makes no sense to compare Spring and Java EE because they have totally different purposes)

    The problem I have is totally summarized with your “Yankee pragmatism”:

    “Here is a bit of Yankee pragmatism for you — I don’t give a hoot about EJB 1, EJB 2 and J2EE. It’s about as relevant to me as who fired the first shot in the civil war :-).”

    On your website you claim that you are helping your customers with EJB for years and you are actually working with EJB2. (and your bio even says that you are working with Spring 🙂 So you suggested people to use these open technical standards like EJB1 or EJB2. And what are you telling them today? Customers who have spend millions of EUR to build their applications? I can imagine: “Hey guys, I don’t give a hoot what I said last year. Now I am an Java EE 6 supporter and you either migrate all you code or you are an non-technical imbecile which I personally despise with a passion” 🙂 So more a “cowboy mindset” – which can be ok in some environments (maybe startups etc.) but can be very dangerous in others..

    I am really happy to see your technical examples and hopefully get some running code from you. I hope you will use AJAX/JSF so that I can take some heapdumps to show you how your sessions look like and than we can deep dive into scalability discussions. I also hope that you use pure JPA2 for DB access and I will be happy to discuss with you the performance of your code – especially if we talk about batch processes which guys like you often forget 🙂

    And to summarize all this:

    – I agree with you that Java EE 6 is “simple, modern, streamlined, innovative and open”.

    – I agree with you that “More a$$ kicking features on the way with Forge, Arquillian, Seam 3, Apache MyFaces CODI, Java EE 7 and many more from the Java EE ecosystem”, also I have to say that I don’t know MyFaces CODI.

    – I agree with you that Spring is mainly “bound to single vendor”

    – I disagree on “Spring 3 – complex, bloated, legacy-heavy, hardly innovative”. I think that Spring 3 utilizes a lot of Java EE and gives you free choice of GUI frameworks, DB access, etc and it gives you additional features like Spring Batch, Spring Roo, Grails etc. And I am saying this based on my personal experience, using Spring for years and not because of any business interest.

    – I think that it is still a risk to adobt CDI today, because it is a first version – even I also think that it is a good version. There might be projects where this is not problem but if you base a software on it that will have to live for more than 10 years than I think it is better to base it on a more proven technology. Many other Java EE standards are proven enough to be used without any bigger risk.

    I also hope that we meet someday personally drink a beer and discuss this all in details, as I think this would be real fun 😉

  • Reza Rahman

    Thanks for the clarifications — they are sensible and I agree with a lot of it :-).

    Look, I know it can be offensive to some people but I am thinking language/culture must definitely be an issue here. Given what you just posted, I am not sure what to make of the original sentences that you had like “Java EE 6 is not a standard! Because it is not established!”.

    If you really have people on the team that work inside the JCP (or other standards bodies) in a significant role and spend hours of their personal life trying to advance the causes of vendor neutrality and interoperability, can you see how statements like these could be highly irritating and distract from the rest of what you say?

    Since you brought it up, below is a few more details about me that might help you understand where I stand. I have nothing to hide and am happy to share it:

    * I am one of the first people I know that wrote a Servlet. I’ve been following Java EE ever since.
    * I’ve never used EJB 1 – didn’t have the opportunity.
    * I’ve successfully used EJB 2 – but not as is. I’ve always avoided Entity Beans and have stuck with Session Beans and Message Driven Beans. I used JDO/Castor, home-brewed JDBC frameworks, TopLink and Hibernate instead of Entity Beans. I used Cactus for EJB 2 testing.
    * I hate XML with a passion. Even with EJB 2, I used XDoclet.
    * I actually had fun developing with EJB 2 and have never had a failed project because of J2EE.
    * I am an early adopter of Spring primarily because of DI and better testability.
    * I stopped recommending EJB 2 as soon as Spring came along but many of my customers still use it (there’s little I can do to change that).
    * I really disliked Spring from the get go because of the configuration complexity. It makes simple things harder than they should be. I also really hate Spring AOP/AspectJ for the same reasons in addition to the Spring issues I already mentioned. Lastly, I hate Rod Johnson’s commercialized anti-Java EE FUD.
    * I loved EJB 3 and Seam as soon as it came out.
    * I stopped actively recommending Spring as soon as Seam came out.
    * A lot of my customers still use Spring anyway (there’s little I can do to change that).
    * I think Java EE 6 really rocks and Spring 3 sucks in comparison big time.
    * Spring’s last saving grace is that it has wide deployment and a large array of supporting APIs. The bad news for Spring is that I don’t think this will last long because of the rapidly evolving CDI plugin ecosystem including Seam 3 modules. Spring might start to look like Struts 1 when compared to JSF 2+plugins.
    * I hope SpringSource is smart/humble enough to adopt Java EE 6/CDI/EJB 3.1 soon and come up with their own kick A$$ lightweight application server, just like Resin :-).

    Make more sense now?

    I’ll keep your suggestions in mind while developing the comparison.

    It’ll be a pleasure to chat face-to-face any time. I think your and my levels of sensitivity might be different. I took no offense to anything you said and you are certainly entitled to your opinions (that’s what freedom is about, right?).


  • Reza Rahman

    OK, after that long and tedious post, let’s now deal with the “upgrade/porting” issues you alluded to (alas another long and tedious post :-().

    Believe it or not, it is something that is a top priority for vendor like us (Resin) and JBoss, GlassFish, etc so we put a lot of thought behind it…

    Now, I won’t tell you that you are completely wrong, but I will tell you that you are mostly wrong. Here is why:

    * Change is the only constant in the IT world. Everyone expects upgrades whether they use Spring, Java EE or whatever else. In fact, this is what agile refactoring is all about!
    * All major enterprise platforms are meticulous about backwards compatibility (well maybe except .NET and Ruby). For Java EE, it is almost a cult. Do you know that Java EE 6 application servers are still required to support both Java EE 5 and J2EE? This means that even when you upgrade you can run exiting applications side-by-side with new ones or port over gradually and incrementally. You can even have old components talk to new components — it’s all taken care of in the spec.
    * You can also simply run a new instance of an application server and run the newer applications on those and leave the old applications alone. Running a few new servers is trivial for most modern enterprises, especially with the cloud :-).
    * Java EE is actually quite conservative about new releases. Generally, a Java EE release happens once every two years — hardly a great burden for most IT shops :-).
    * You can easily upgrade almost all Java EE APIs like JSF, JPA, Bean Validation and JAX-RS on a piece-meal basis because they are designed to be pluggable like Spring. Now, this also means that you do need a platform upgrade if you want to use a newer version of non-pluggable APIs like Servlet, EJB or CDI.
    * To alleviate this problem, CDI introduced the portable extensions SPI. What the portable extensions SPI does is allow you to use more cutting edge innovative features in plugins-like Seam 3 and Apache CODI until you get a chance to do a full upgrade of your platform. The portable extensions basically serve as an innovation laboratory for future versions of CDI, Servlet, EJB and pretty much any other Java EE API.
    * Upgrading commercial offerings like WebLogic and WebSphere in very conservative, large corporations can be a pain. However, if you give it an honest try, you’ll find that upgrading more modern, “sane” application servers like JBoss, GlassFish and Resin is a snap. In fact, GlassFish is fantastic at real time upgrades with almost no IT intervention because of their OSGi kernel! I can tell you first-hand that most Resin customers are quite proactive about upgrades — in fact so much so that they push us to do bi-weekly releases! If you talk to people GlassFish and JBoss they will tell you the same thing.
    * I do want to be fair to WebSphere/WebLogic — they are also trying to make upgrades painless by adopting OSGi like GlassFish. They too have learned from the J2EE era mistakes :-).
    * Upgrading Spring is really no picnic. In fact, I would say upgrading a Resin version is probably just as easy as upgrading Spring for more than one application on a piecemeal basis :-).

    Hope this sheds some more light as to why “Yankee Pragmatism” is not as bad as you might think and is quite fitting for the agile age :-).


  • Mirko Novakovic

    29. May 2011 von Mirko Novakovic

    Thanks Reza for your last posts. First of all I want to say that I do not feel personally attacked 🙂 I like to discuss hard and if I wouldn’t I could just press the “spam” button.

    First I would like to clarify my arguments about the “standard” topic – think it was a little bit confusing – especially in English.

    Of course formally all JSRs in Java EE 6 are a standard – accepted by the Java community and regulated by the JCP. Most of them are developed in an open process with lots of open discussions and lots of companies/people involved.

    What I wanted to say is that I see a big difference between the different JSRs inside the Java EE standard and that for some standard I see a big advantage (e.g. Servlet API) and for some I don’t see an advantage of standardizing the API (like JSF or CDI) – sometimes I even think that it is a disadvantage. That’s why I think it is wrong to recommend people to use JSF just because it is a standard. Hey – I see sales of big app server vendors saying this every day: “If you use Spring or GWT or Wicket, than you are not sing you application server, you are not using the Java EE standard and you will have problems in the future”.” – hope you agree with me that this is totally wrong.

    So I will try to write how I see the Java EE standard with my experience of 12 years Java EE (J2EE) development in mainly big environments like insurances or banks. (so it is a subjective opinion)

    For me the first and most important role of the Java EE standard is to specify and develop the contract of Java Enterprise application servers. Where application servers are infrastructure components in operations and run Java Enterprise applications that are developed under the constraints of the Java EE standard. Some of the JSRs (mainly the older ones) still do a good job to specify this contract between application and infrastructure: Servlet API, JMS, JTA, JMX, Security APIs, …

    These APIs are more the basic technologies and there is not much innovation in it. So a long release cycle is ok for them. With release cycle I mean the time between two application server versions are installed (with the newer one supporting the newer Java EE version). Java EE 5 was released in may of 2006, Java EE 6 was released November 2009 and Java EE 7 is scheduled for end of 2012. So there are approx. 3 years between releases. My customers who mainly use WebSphere have mainly just upgraded from WebSphere 6 to WebShere 7 or are still in the process to upgrade. That means Java EE 5 is now (5 years after the spec was released) available for development and Java EE 6 that will come with WebSphere 8 which will not be available in production at my customers until 2012/2013 – maybe even later. You can now argue: This is there problem just take Glassfish or Resin and everything is fine but this would be the “developers dream” but not the reality I see very day.

    This is no problem if you look at the APIs I would call the infrastructure contract, e.g. if you develop against Servlet 2.3 or Servlet 2.4 is not a big difference.

    If you look at other JSRs like JSF, EJB or CDI I see a big problem with these release cycles. Look at JSF as an example.

    JSF 1.0 was released in 2004 the main idea was to develop a component based web framework so that vendors could develop WYSIWYG tools and component libraries. I was one of the early adopters of JSF and really liked the framework BUT it was painful in my project. You couldn’t use JSTL, it was hard to implement a HTML design you got from your customer, MyFaces was very buggy, etc. Other “workaround” frameworks helped to solves these issues (like XDoclet helped to survive EJB2) but still it took years to make JSF a stable framework. The whole lifecycle still is pain in my point of view – it is far away from being easy to understand, especially if you need to write your own components. Then Web2.0 and AJAX came up and JSF was never designed for it – you see this problem if you look at the server side state and how big it can grow,which is pain for scalability.

    So my point is: Why should we put frameworks like JSF in the Java EE 6 standard? Wouldn’t it be better to just put the infrastructure APIs in the standard for Java app servers? You could also make JSF it’s own JSR with it’s own release cycle on top of Java EE.

    The SPIs are a good approach to get around this problem – just have a core framework specified and let other frameworks drive the innovation vis SPI and plugins. Also the introduction of profiles are a good start to make app servers more lightweight but still the release cycle will stay between 3-5 years.

    This is why I think you have to carefully look at the JSRs inside of Java EE 6 and I distinguish between “real” standards (infrastructure) and frameworks that are part of the standard.

    Where I totally agree that you have to use the infrastructure standards, I think you have to be careful with the frameworks because there are pros and cons that you have to consider. This is why I had a problem with the recommendation of the author who said to always use the standard if possible.

    Still I think it is hard to get my points written down but I hope you get the points.


  • Reza Rahman

    It’s good you are not taking any of this personally. These are hard topics and I’d fall asleep writing them if I didn’t put in a bit of good-natured banter here and there :-). If you pressed the “spam” button you would be misusing it as a censorship mechanism, wouldn’t you :-)?

    Your interpretation of Java EE as “infrastructure” is of course just that — an interpretation (with SpringSource being it’s largest proponents of that interpretation). Believe it or not, all of what you mentioned was discussed in detail during framing the Java EE 6 Web Profile so I can simply give you a glimpse of the discussion there:

    The problem with treating Java EE as minimal infrastructure is that it misses the central goals of standardization — promoting compatibility, interoperability and vendor-neutrality (which seems to be concerns you do understand). In absence of higher level APIs like CDI, JSF 2 and EJB 3.1 what you would wind up with is either a wild, wild west of non-compatible solutions (like all the frivolous Java web frameworks that unseated Struts 1 as a “de-facto standard”) or worse, vendor monopolies (like SpringSource). Both are very unfavorable outcomes for Java developers in the long term…

    Having said that, let me agree with you on one thing — there is a definite danger to standardizing APIs that are poorly understood or under-standardized. EJB 1 and EJB 2 Entity Beans are good examples of that. Anyone suggesting that those be adopted “just because they are the standard” is/was clearly wrong.

    However, it’s important you realize though that those times have changed. People in the JCP are now much more careful about under-standardizing/over-standardizing. This is certainly true of Java EE 6 APIs.

    The point is that you should carefully evaluate a standard on its own right. Just like it is wrong to blindly adopt standards, it is also equally wrong to blindly avoid standardization.

    It seems to me the latter is what you might be doing for CDI and quite possibly for JSF 2, EJB 3.1 and JPA 2 as well. Now, it is not impossible that I am wrong (although it’s honestly unlikely) — which is why I want you to specifically outline what you think is missing instead of the generalities that you have now. For one thing I can get them fixed (if they are indeed valid concerns).

    As to JSF, here is my experience with it:
    * Yes, JSF 1 was mismatched to JSP and JSTL.
    * I still loved it compared to Struts and pretty much any other Java web framework out there, even today.
    * I am an early adopter of Facelets and RichFaces – I think both are fantastic frameworks that effectively make up for the issues with JSP/JSTL and AJAX.
    * JSF 2 totally rocks!

    As I said, I don’t have a very high opinion of WebSphere, WebLogic myself (they don’t even bring much to the table in the JCP). I don’t want to work on those platforms if I can help it (one reason I tend to avoid large companies in favor of start-ups). If you look at most Java EE adoption, it is happening on JBoss, GlassFish and Resin instead in small to mid-sized companies.

    In your case, I would say that you should look into pluggable CDI runtimes like OpenWebBeans or Weld and use it in conjunction with other pluggable Java EE APIs like JSF 2, JPA 2, JAX-RS and Bean Validation. I think those are all first-class APIs much more usable than Spring in addition to being vendor neutral :-). You could use Seam 3 or Apache CODI for the parts that EJB 3.1 provides (both are CDI pluggable extensions) as well as some of the things that Spring provides beyond Java EE.


  • Reza Rahman

    BTW, I am finding this discussion fascinating/very helpful. I hope you are as well.

    Thus far, other than writing a detailed Spring 3/Java EE 6 analysis, I can see at least three more blog posts coming out of this — “Is upgrading to Java EE 6 difficult”, “Is CDI immature?” and “Is Java EE portable?”. Can you think of others?

    P.S.: I’ll leave out you and your company out of any follow-up to this. You are of course welcome to discuss some of this with me again in another, probably broader venue :-).

  • Mirko Novakovic

    29. May 2011 von Mirko Novakovic

    Reza, I wasn’t aware of the discussions and can understand the points you are making. Like always: This is a complex problem area and there are rarely simple solutions to complex problems.

    I will have a closer look to Seam 3 in the next weeks. Just wanted to download the PDF documentation but the link is broken. Here the correct link:

  • Reza Rahman

    OK, great. Do let me know if I can help. If you (or anyone else) want, you can reach me personally at or 717-329-8149 (my cell phone). It is not unusual at all for me to exchange ideas off-line (with many people around the globe – very few actual Resin/consulting customers :-)).

    One of the things we as Java EE vendors have failed to do historically is be more involved at the grass-roots/community level on a one-on-one basis. Things are getting better with me, Arun, Adam, Antonio, Alexis, Lincoln, Dan, et al but there is still much to be done.

    At the end of the day, it is important that we talk to and properly understand where folks like you are coming from so we can do the things that really need to be done.

    Even if you don’t reach out, I do thank you for the discussion. Also, I invite you to listen in on the new Java EE 7 JSRs. Anyone can do that (without joining the JCP) through

  • andrej m

    12. July 2011 von andrej m

    Very interesting exchange. I think Mirko wins for keeping his cool and being objective. Reza is too partisan and has axes to grind. The bottom line is the difference between de facto (Spring) and de jure standards. Or free-market standard vs. centrally imposed standard.

    – andrej

  • d0natas

    18. January 2012 von d0natas

    Thank you guys for the discussion.

    Some thoughts:

    Developers of enterprise applications normally focus on solving business problems. They are happy to use a technology which allows them to achieve desired (business) results. Spring (or Rod Johnson with his book) came out in a past and made a lot of them happy (me too:). Like Mirco states, spring proved itself also as being portable during a lifecycle of enterprise applications.

    Some parts of J2EE (discussed here) proved them self as being a big trouble.

    I am very happy, that JCP learned from that. The discussion and posts from you guys (Reza, Adam) makes me believe, that new parts of JEE 6 (CDI) are mature enough to be used straight from a beginning, regardless of their virtual status as “version 1.0”.

    But only to believe is not enough to achieve a deterministic results.

    So like always i do my “homework” and validate JEE6 by doing “real” scenarios – but not at production systems yet.

    Like Mirco states, one is limited by a customer environment in the enterprise area due to decisions made in a past. Normally the people use their experience to make a decisions (J2EE = bad experience). If some framework proves itself, they stick to it for some time. I think, being just a formal standard is not enough to get them back – some disruption is required too.

    I think also that JEE6 brings enough disruption to become a standard in all facets (de facto, de jure etc..).

    • Dr JEE

      >> CDI is missing critical features like transactions or
      >> asynchronous processing which are available in EJB 3.1.
      >> – supposed quote from Adam Bien

      CDI and EJB 3.1 are complementary, not mutually exclusive. If you are using JEE Web Profile, then you can use CDI + EJB 3.1 lite (managed objects), without transactions. CDI does support async CDI events (in memory object communication, as opposed to JMS). If you are using full JEE, then CDI link web code to EJB with transactions and async for free.

      Adam is very pro CDI & EJB – and pro their use today. Check out his blog… it’s loaded full of advocacy. You’ve totally quoted him out of context above.

      He was saying that you should either use CDI+MB or CDI+EJB – with the difference being that in the first case you don’t use container timers/transactions/async messages but in the second case you do.


      • Mirko Novakovic

        15. November 2012 von Mirko Novakovic

        Hi Dr JEE,

        please read the comments – Adam has commented on my first blog entry and wanted me to put in the whole statement of Java Magazin, which I did. So the quote is correct and not out of context. Just be aware that the article is almost 2 years old 🙂

        If you read my article you will see that it is not about a technology comparison but more or less about the JEE standardization and if this makes sense for all parts like JSF or CDI. And if there is a real advantage if such technologies are standardized.

        I still see many projects chose JSF with the argument: “It is the standard” – for me this is just a bad argument and JSF in some projects a bad decision. So I wouldn’t make JSF part of the standard and I wouldn’t use the argument to select JSF. That’s all I wanted to say – not only for JSF but for many “standards” in JEE.


        • Yannick Majoros

          14. October 2013 von Yannick Majoros

          Hi Mirko,

          I know the article is old, but I still want to comment on it.

          You seem to forget one big thing. Standards are something different parties agreed upon. Spring or Vaadin are written by individuals or single companies. When some random behavior happens (and it does), you have no specification to know if it’s on purpose or if it’s a bug. On the contrary, I got bugs (=non-compliance to spec) corrected in jsf implementations or in a java ee server.

          I could understand you’re using X instead of standard Y, but don’t say X is standard. It just isn’t. Spring is a one-company product, nothing to do with a 500-pages specification with multiple implementations.

          As of Hibernate vs JPA, is there any debate left? I haven’t seen exclusive Hibernate usage for years, and it’s better like this. You could just use JPA for 99% and leave the last 1% to your proprietary implementation (Hibernate, Eclipselink of one of the others). That was even true for JPA 1, using it won’t kill your second level cache. It’s not like JPA and Hibernate are two different beasts, Hibernate just implements it.

          As someone said, Spring made a great job of filling the interim when EJB 3 and CDI where not there, some years ago. But if the standard gives you about the same level of features or better, just use it. Same for JSF, which is superior in my opinion to all those unspecified toy frameworks.

          • Mirko Novakovic

            16. October 2013 von Mirko Novakovic

            Hi Yannick,

            thanks for your comment.

            The first part that you claim for Spring and Vaadin is also true for the implementations of your standard (let it be Tomcat, JBoss, WebSphere or Weblogic) – bugs will be fixed in the same way (or even worth in the non Open Source implementations) as Spring & Co. The documentation of Spring, Hibernate and also Vaadin is extremely good and you will get at least the same information as from the standard docs. Look at book of Vaadin for an example of great Open Source documentation:

            Anyway you can use the standard if you are happy, but I also think that these technologies are older than my article now and have not really improved. Take a look at things like Spring Data, Spring XD, Reactor or other stuff that are defacto standards like Twitter Bootstrap or Jersey or or or…

            Where is Big Data and Cloud in Java EE, where is modern UI, mobile? (maybe JavaFX is on a good way, but forget JSF)

            Do you really think that JSF is superior than any of these modern OSS framework like Vaadin, AngularJS, Wicket? JSF is maybe one of the worst so called “standards”. Take a profiler of your JSF application and check the memory usage of your session…enough said 🙂 I can really just tell you that I have seen so many customers struggeling with JSF as it doesn’t scale at all and has a very bad adoption of modern RIA application architectures or even ROCA style ( applications…


  • David


    When you decide to go toward Spring Framework, more or less at 2002-2003 years, Spring wasn’t an standard. Why we can’t do the same now?, why we can’t go towards Java EE + CDI + … standard specification instead Spring Framework, in fact Java EE is easier than Spring?
    I think that in fact, Spring defenders are afraid to lost its status, its knowledge in developing Java Enterprise Applications

    • Mirko Novakovic

      19. February 2014 von Mirko Novakovic

      Hi David,

      you can do it if you decide that Java EE + CDI is easier and better for you. And as the article is already three years old, I think CDI is mature enough to go for it as a DI framework.

      My message is still valid: Decide for it because your requirements fit with CDI or JSF etc BUT do not decide for it because it is a so called “standard”. Today I would rather use Vaadin or AngularJS than JSF and if I look at projects like Spring Data (for integration with NoSql datastores), Spring XD, Spring Batch, Spring Social, Spring Mobile, Spring HATEOAS etc etc I am still convinced that Spring is a good choice together with Java EE. But doing Vaadin with CDI would also be ok for me if its a good fit.



Your email address will not be published.