It’s not Spring anymore is the summer of JEE7, ready riding the wave?


I wanted for so long to write my thoughts about this subject.The past couple of years I have been coding entirely in projects that required an Enterprise environment and were mostly enterprise applications with exposure to the user through a Web UI. This would include high scalable mobile marketing systems , billing systems and lately workflow systems. The past year I have been developing my own idea and I came to the point where I had to take some decisions around the debate of using or not Spring in my application. The application uses as major deployment platform, WildflyAS 8.0.0 Final(fully JEE7 compliant application server) at the moment, formerly it was JBoss 7.1.1(fully JEE6 compliant application server) but I switched to the latest fully JEE7 compatible application server. Having a long history with JBoss it is the application server of choice.

I know the product since version 4.0. Despite all the criticism by the competitors, it was the only product that would give a fully functional JEE5/6/7 stack implementation for free offering also clustering. I have much respect for Glassfish also, but the RedHat way was more my way, and when I meet one of the guys I was looking up, Arun Gupta, and he told me that he was moving to RedHat to lead the developers advocacy dept, I was even more excited. I had the opportunity to talk with him while he was attending for a talk in the local Java user group in Luxembourg. Collaborating the past few years with a lot of Spring lovers, I came to question the necessity of having as production tool an application server which is, yes “heavy weight”, offers “many more things than actually need it” than what you actually need and is problematic with libraries. So I started introducing to my project with some friends Spring. Our platform is supposed to be a big data platform for real time statistics on usage of affiliate networks and other marketing stuff. I decided to give it a shoot and we started springing and tomcating everything. After some time I started to notice that the caveats of JEE5 /6 were simply transformed, in a worse manner. I took the decision to migrate everything to JEE7. In the following paragraphs I will explain my myths and realities by using both worlds.

Heavy weight

Please, for God’s shake(in any God you may believed), in the era where commodity server for deployment of a testing environment is a cluster of 4 nodes with 3 i7 8core CPU with at least of 16GB or RAM each, talking about memory consumption can only sound funny. On top of that I would add, have you ever tried to simulate a JEE environment with Spring and a Servlet(Jetty,Tomcat) compared to that of full fledged application server. I can tell you that in our case it was nothing but a few megabytes more on the application server side.Yes the application server is heavier in terms of memory.No argue about it, but in production systems in big data centers where maintainability and support is more important, Tomcat isn’t a choice. Check for example the switch European Comission is doing migrating every application in full JEE application server from Oracle. And for those of you out there, Servlets are NOT application servers. The fact that you simulate all these by using Spring is a naive approach. TomEE a ,very nice try @dblevins is a big effort and works really good, to bring JEE stack in Tomcat in the correct way by following the specification. Please also bare in mind that the simplicity of the configuration of an application server for a starting developer is far more simpler than Spring. The simplicity of the tools should attract and not the hype around it. By the way have you tried to cluster Tomcat farms? Have you given a shoot of Wildfly 8.0.0 .If not before deciding I urge you to give it a shoot.

Many more things than…

The application server loads far to many things. Another big myth, evangelized by several Spring guys. All application servers, these days offer several profiles for starting up with different level of services. All these are configurable. In my environment with the full configuration of Wildfly, the application server starts and deploys the entire stack of my application in less than 20 secs. Other products like Glassfish  offer the same capabilities. Profiles are now a major standard for the JEE community and bring the JEE one step further. In the same configuration with enabling the same spring contexts for the same services it was 14 secs for a Tomcat. That didn’t include initialization of the transaction management. This would lead in a difference of 4-5 secs. I rest my case on that, yes is a bit faster…BUT I had to boot up hornetQ myself and Mule ESB myself + Camel. Adding these boot times you are in the same boot times and of course the manageability of your environment now becomes far more complex. In order to simulate that and be more accurate, I enabled the managing of HornetQ through the Spring context. Doing that, voila, the magic is gone. The environments are equal the need the same time +/- 1 sec to boot up everything end to end. Have you tried to configure all these things alone?Bet you, that at some point you will be frustrated. Using JEE7 and a fully compliant JEE7 application server like Wildfly 8.0 or Glassfish, the only mandatory things is the definition of dependencies and to know the deploy folder. The new JEE7 specification simplifies the programming and deployment model by giving the chance to Java enthusiast to focus on what is important. That is the fun of coding and creating amazing products.

Libraries and jar hell

Classloading was and remains a kind of black magic to the new comers in the java world. Endless debates have been going around for years for how application server and servlets are loading libraries. People were accusing appservers that do not respect the libraries of the users. A big hype. Since the JEE5 the loading of classes was more or less standardized. Problematic of course I will admit, but it was clear. The fact that everyone was opting the hierarchical model, was creating issues. I will admit to that.But have you tried using Wildfly and the new JEE 7 standards?Thinks have radically changed.Coming to the point of jars also, I challenge everyone to create a project using JEE7 and Spring and then list the dependencies you have. JEE7 solves this issues. No problem with mis compatible libraries and versioning. After doing the migration from Spring to JEE7 my war contains 8 jars!Yes I know you wouldn’t believe it but it contains 8 jars. Which are deps to the JEE7 API’s and to libraries I have created. Have you tried maintaining different libs than what Spring would ask you to and try to solve the version conflicts, because the framework A wants a version X of  a jar and Spring requires version Y? I know it looks like trying to solve the typical assignment problem in computer science with JARS as resources. With JEE7 adoption,you will only need to reference the API’s and let the appserver provide the implementation. With the standardization of the specification, coding against API’s you can only benefit. Your code will be cross application servers deployable. To that I admit some minor configuration per app server may be required. But no change on your code, example portable JNDI bindings.

Final thoughts

The above reflect findings of a simple JEE7 enthusiast which looks at the technology stacks out there from the perspective of the new comer and new developer. Yes JEE7 is a mature enterprise framework to develop upon. The new features including the robust CDI, is solving many issues that the spec had in the past. The maturity that came through the community process, has evolved the framework to be more robust and simplified the configuration and programming model for the new users. I don’t understand the fanatic polemic for JEE. Our community I firmly believe have lost the battle of hype. But in real enterprise environments JEE7 is becoming the defacto choice and application servers are again coming back as the default deployment platform. On the other hand I will not take anything away from Spring. Yes is a good enterprise framework, mature and extensively used. But going forward and taking correct decisions opting for a vendor specific implementation locks you in to technologies you may don’t have the opportunity to change in the future, with the fast pace of changes in our world. I don’t neglect that the Spring community is adapting fast. But providing unified environments and ability to change, for me are far more important factors. As  a person I would like this Spring against JEE fight to come to an end. Both frameworks are taking and giving to each other ideas. You can stand as a soldier behind vendors and blindly follow orders and evangelize technologies, or you can be on the fun part of people acknowledging that the most important thing is the creation of framework and tools that provide freedom.  I think that the JCP process as such is a very nice place to be and involved on the specification of standards, which are lead by the community and of course backed up by major vendors.

The 100$ question for the “experts”

What is the difference of having an EJB3.1/2 with a Spring bean which is annotated as @Transactional?

(please don’t start talking about the older versions of EJB’s because I will admit that the specification back then was not mature enough..but as a JEE guy the difference is that I will admit the caveats of the framework.)

29 thoughts on “It’s not Spring anymore is the summer of JEE7, ready riding the wave?

    1. I wouldn’t say so.Again it’s not a matter who is doing it better. In my case I know alot of companies adopting really fast jee7. I don’t trust that much sites and metrics other to my own eyes. And an argument about job posting isn’t a real argument. I state clearly in my blog that I won’t take anything from the Spring community, because I firmly believe they do a great job. I don’t agree with the fact that they keep promoting themselves and having a polemic behaviour against a different proposal. We become better through discussion.

  1. Great post. We left behind Spring five or six years ago, when we meet Seam Framework. Now, JEE had taken the right direction. Spring is just for legacy projects. I prefer JEE for new projects anytime.

  2. I agree in principle JEE and Wildfly is the best choice for new projects. Unfortunately in the real world of mature Spring 3.x based legacy applications, migrating such an application to JBoss/Wildfly is not a sensible option. The problems with Classloading, Oracle AQ & custom resource manager are a major hassle.

    Application servers also try to second guess that libraries that my application use. (JBoss modules are a perfect example) Even what messaging platform I want to use.
    We attempted to disable HornetQ as the MDBs were triggered via OracleAQ, turns out it’s not possible.
    ActiveMQ configuration was also far too painful.

    You speak about vendor lock-in, when using a full application server, the developer still needs to package the various vendor specific descriptors so the benefits are questionable.

    1. Keep in mind, no standard (SQL, HTML, Java, Java EE, etc) can guarantee 100% portability. The key difference is that standards make it far easier to remain vendor and implementation neutral. Gavin King explained this point well some years ago, it’s well worth a read:

      As to the WildFly/JBoss issues you mentioned, I strongly suggest following it up with them – it could be a bug since that’s a case that’s supposed to work seamlessly via JCA (JMS vendor pluggability). If you are not going the JCA route the server expects, I can see a lot of issues cropping up (including in production).

  3. Speaking of metrics, it’s interesting to see Google Trends on Spring Framework vs. Java EE: In terms of adoption, we see continued strong Java EE uptake in the GlassFish, WildFly and TomEE user bases. Here are just some of those stories:, not to mention at JavaOne year after year: I’d say the reports of Java EE’s supposed imminent death have been greatly exaggerated :-).

      1. Your metrics would stand true, if the comparison was done against the correct facts. Comparing Spring MVC and Java EE is not the same.Spring as a hall framework with Java EE yes. I am not afraid to admit that the UI part of Java EE in the past was not as mature as someone may thing. But I firmly believe that after the version 2 of JSF simply people have moved away. Having taste both worlds, I would say both fit different needs. Also have a look that in JavaEE 8 the MVC 1.0 JSR is there accepting that this part was missing from the platform. Now JavaEE 8 will offer two UI development models, which adds an extra tool in the developers arsenal.

  4. We are a gaggle of volunteers and opening a new scheme
    in our community. Your site offered us with useful info too work on.
    You’ve done an impressive task and our entire group can be grateful to you.

    1. Hi ,
      thank you for your kind words. I am only a developer with some experience trying to blog on problems that not experts are facing and sometimes is a burden to dig up for the solution. Soon I will be posting the part for the SMSCE code on the code part to send SMS in the SMPPSim and routing with Mule and Wildfly…stay tuned. I would be happy to hear/learn about your community

  5. Interesting blog. I would say the answer to your $100 question is that EJB 3.1/2 beans are not only transactional, but allow you the option to have stateful as well as stateless managed beans. You also get nice contextual dependency “outjection” capabilities with EJB 3.x and CDI. Good stuff, indeed, but this can also cause unintended additional complexity around performance and failover in clustered environments where the app server is supposed to magically handle these things but doesn’t always do so in the way that you want or expect. I would argue that you can accomplish the same things with Spring, but Spring attempts to be more stateless, especially on the back end. So, the debate continues to rage, it seems… Both Spring and Java EE attempt to accomplish similar things. Although Java EE has come a long way and has gotten much better over the years, Spring became the “de facto” standard because Java EE was slow to evolve. And while Java EE continues to improve, the pace doesn’t seem to be getting much better. I actually like where Java EE has come. I worked on a large Seam project years ago, and really like some of the standardization of the Seam features. I still prefer Spring because it is still more portable than the JEE specification. I work for a company that develops and maintains an eCommerce framework that is built on Spring. In order for it to be useful to our clients, it must be portable and extensible. Because we package and provide Spring as the “container”, it allows us the ability to consistently hook directly into Spring’s internal components to control and override certain behaviors of the container, allowing our clients to easily override and control our default eCommerce components. This creates “vendor lock in” for us as a software company but allows us to be locked into a consistent, portable, “de facto standard” open source platform. If we were relying on a JEE application server and a generic specification, then we would not have the flexibility that we have. That said, Java EE7 is certainly a vast improvement and a good specification. Having two major competing Java enterprise application development platforms is a good thing, The notion that one is better than the other and therefore we only need one nonsense because they are both good and the existence of both drives innovation. I’m looking forward to seeing how we can begin using Spring Boot on our project. I’m sure others have plans to begin excellent new projects on JEE7.

    1. I completely agree with the notion of who is doing it better. I strongly believe for example that spring batch was really nice work and provided a guide to JSR itself. That’s why in my blog I state that I will take nothing from Spring. My only problem is that people tend to give wrong impressions.My argument is that what you do with annotation and configuration in Spring does the same thing. But now in Java EE7 you can have lightweight beans. With the new specification of portable CDI injection and some suggestions on improving JNDI specification I firmly believe that the specification will mature even more. Coding though against a specific vendor doesn’t make you that portable. You simply state clearly that in order for my platform to work this are the preconditions. Which is also a decision someone must take. But I would like to compare the Beans in Java EE7 with Beans definition in Spring. The differences aren’t that big. Also in the Java EE7 even before EJB’s were refered as components, and by definition and job they can’t be that lightweight. But compare the complexity of making an EJB clusterable with any other type of component. I would like only to make clear the arguments on each side, because I believe both enterprise platforms are really good. On the comment of pace, I totally agree with you. In the past the JCP was a bit rogue and not reacting to changes that fast. But nowadays the major vendors supporting Java EE are listening more the community. Even me that I am a nobody I was able to make some suggestions that in my perpsective will help. Also the adopt a JSR thing is something I loved. Keep hacking mon ami and give a shoot to Java EE7 ;).

      1. As to velocity of change, I think it should be noted that unlike non-standard products, it is best standards are stable and take some time to mature properly. Beyond purely the standard though it’s hard to make a case that the Java EE centric ecosystem isn’t just as agile as Spring. That being said, many folks since Java EE 6 are actually saying that the standard is feature complete enough and extensible enough for them not to be too concerned over velocity of change.

        I will say in your particular case something like Spring or Weld+DeltaSpike makes more sense since you have a reasonable need to decouple as much as possible from the target runtime.

  6. Great post!
    I’ve been on a journey with a system initially designed 1999 with J2EE, VAJ, Websphere and even Entity beans!
    Along the way around 2007, stuck on WAS6.1(J2EE), someone pushed the panic button and Spring was introduced. That was probably the right decision, to get rid of EJB2.1 but a huge mistake was done not convert everything to Spring immediately and we were left with both Spring DI and EJB2.1. The XML-mess with Spring and the incredible complicated constructions to make both systems work together made us despaired.
    After many tough decisions, we went along with Spring until we changed appserver to JBoss, hello JavaEE 6!
    Now, Spring DI and EJB2.1 is out, replaced by typesafe CDI and EJB3.1 and we are very happy now, refactoring is possible. The biggest problem for us to do the migration was the fact that lots of unit tests(someone might say integration test) was totally dependent on Spring. Spring is a large ecosystem with good parts, e.g. Spring JDBC but with the development of JavaEE standard, it’s not many arguments for me to choose Spring when designing or refactoring a system.
    I think it’s a little bit strange that people choose Spring on top of a Tomcat. You are already on JavaEE, why Spring? I totally agree with you regarding Servlet engine in production. When performance issues are coming, you don’t want to be on a Tomcat.
    Also agree with you on the dependency hell. Our solution to beat Spring dependency hell was to cut off transitive deps and only include runtime deps we knew we needed(trial and error). Maybe dangerous but I think it was the correct thing for us to do.
    I’m not so afraid of the portability issues anymore. We was able to change from Websphere to JBoss pretty easy. Maybe if you are into vendor specific stuff it could be hard. The most important thing to migrate easy is to have a homogeneous architecture.

  7. Interesting to hear you experience, I’m going exactly the other way.

    After working with JBoss for a good time, I’m tired of Java EE promises, like: “J2EE was horrible, but now here it is the great new Java EE 5”, but then “Java EE 5 was not so great, but now we have done things right, welcome the revolutionary Java EE 6” and now “Java EE 6 was not so revolutionary, but don’t worry, here is the solution to all your problems, the Java EE 7”, and the story goes.

    The fact is that the “work out of the box” promise is not true. We have a great team here (including one guy that is going to work for RedHat as a JBoss consultant), but even though, we spent weeks configuring and trying to make things work right in a 4 nodes cluster in our production environment.

    Recently, I have a chance to use Spring 4 in a project and I see “how life can be simple”!

    I also can’t stand people at Java EE communities blaming Spring after its contribution to Java world. It’s even a sign that they can’t see how behind they are. They’re doing some things right now, but that should have been fixed years before. In areas like Enterprise Integration, NoSQL and Big Data (to list a few) Java EE still can’t compete with Spring.

    1. But there is were you are wrong. I am not blaming Spring. If you read carefully my blog entry I state clearly that I consider Spring a really mature framework and that I have used it and of course it offered way to many stuff in the java community. I am just stating and trying to address some myths. Also as you will see I don’t have the same “polemic” behaviour like you have agains javaee. There is no perfect framework and there is no silver bullet. The only thing is you have to chose wisely what are you using and for which reason.

      1. Sorry for not being clear. I was not referring to you when I said “blaming”. I was referring to blog with posts like “Why X is dead and Y rocks” and stuffs like that (examples: and But this kind of things exists on both sides, I know.

        I also didn’t have the intention to be polemic. I was just trying to express some of my disappointments. I totally agree with the “no silver bullet” argument, that’s why I’d like to see these two communities fighting less and collaborating more.

  8. Great article.
    Although the big weakness of J2EE is testing frameworks as for me. And I don’t know how to develop robus application without test coverage.
    I have experience with both Spring Test and Arquillian framworks. Arquillian looks very similar to Spring test for this moment. However, in practice it turns out to be a nightmare to support these test. And development with Spring eventually bacome much faster than one with J2EE

  9. Without proper mature MVC framework JEE is still dead on arrival. That’s one of the strongest points of Spring and its the first thing people who develop a ‘modern’ web application look for. Even Microsoft recognised this years ago and introduced MVC in their .Net framework, but JEE is still pondering its JSR while promoting an archaic JSF approach which no one wants and could never keep up with the rapid developments in web UI techniques.

    1. Hi Joe,
      I would admit that in the past JSF was cumbersome.But with the new way of design of app,where the MVC is done entirely on the client(AngularJS /ExtJS etc), the argument doesn’t hold true. And of course I am also setting criticism on JSF, but the latest version have improved a lot. Judging a framework from the UI technology though is always what was bothering me.Is like saying,because you don’t like the lights of a Porsche, the Porsche doesn’t produce quality cars.Referring always to version >= JEE5. With the arrival of JEE7 actually the 2 worlds have really really small differences.

Leave a Reply to Cheng Hong Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s