Is Spring between the devil and the EJB?

Reading this post on Javalobby prompted me to go and dust off a post I wrote a while ago but hadn?t published regarding Spring and the revitalized EJB standard. At the time I was fired up by this post by Rod Johnson which seemed to be a large helping of FUD and insults. Nonsense such as suggesting that because some people were using app servers and some weren?t the age of the app server was over, like suggesting that because I want a shovel to dig a hole, we no longer need backhoes. This was interspersed with some irrelevant quotes from Gartner made to look like evidence and malicious comments about EJBs and their users. It seemed like the Spring folks were chomping at the bit to pronounce EJB dead when in fact, as evidenced by some recent posts, it is very much alive. In hindsight, it seems the Spring guys were trying to lay some marketing groundwork prior to releasing their own OSGI application server.

This brings me to this latest post, one of a number of recent posts which sings the praises of EJBs and in this case asks the Spring developer “why not?”. It’s almost like the question nobody asks because the presumption is that the answer is obvious. It also touches on the issue of Spring and EJB developers not getting along which I think in part was fueled by the old arguments of Rod and Gavin who seem ‘passionate’ about their technology choices. However, there is still some animosity between the two camps years after those minor flame wars. I think part of it stems from the normal response of users being defensive, and therefore offensive or protective of their technology of choice because of flaws they are aware off even if they disagree with them, which is a normal response.

Disclaimer : I’m currently working on a Seam project and have been involved on the Seam forums. However, when I need a quick dependency injection library (especially for SE), I turn to Spring.

EJB users are having to defend a technology which has the appearance of being stodgy and has a terrible legacy even though its modern day incarnation is far more hip, cool and even Spring-like. Few negative comments about EJBs appear to be about flaws in the current implementation other than the fact that EJBs require a container.

The Spring users have to defend a technology that is in essence proprietary as opposed to standards based, and while the core Spring functionality (DI, AOP) is very good, a number of people believe that it is starting to spread itself a little too thin, and starting to suffer from the dreaded ?Bloat?. It is now facing competition from EJB, a technology that is not only as easy to use and powerful but is also a standard, which, all things being equal, is a positive. If nothing else, being a standard will also give it a helping hand in being adopted in some of the more corporate shops.

While SpringSource haven?t implemented the standards, I?m sure there will be a Spring driven implementation of Web Beans (JSR 299) which could drag Spring kicking and screaming under the standards umbrella. If Web Beans gains traction and becomes the accepted way of defining components for web applications, then there is a chance people will choose the standards based web beans syntax over a proprietary Spring syntax and be able to swap out implementations. One advantage Spring does have is the ability to provide its core functionality on both desktop and web applications which unfortunately, isn?t a part of the Web Beans spec (yet?). This may provide enough reason for developers to avoid using Web Beans or at least limit it to pieces that will definitely be web based only.

I do like the fact that the only opaque part of Spring is the container. Other pieces like the transaction manager, data sources and so on are all transparent for you to see in your configuration unlike the EJB container where they are just bundled in and magically mess with your beans. This lack of apparent simplicity can also be a turn off for some people who prefer a simpler Spring solution over complex old EJBs.

In some ways Spring feels like that small cafe that worked really well, was cheap and served great food compared to ‘those chains’. They decide to open a couple more restaurants up, and the owner can’t run all of them so he hires extra help, and trains them, but they don’t always get it right, and lack the enthusiasm with personal service. He opens a couple more stores up and decides to produce a manual detailing every aspect of the recipes and customer service. Before he knows it, he is one of ‘those chains’, and the quality of food has gone down, and the prices have gone up. Not that I think every Spring project is prone to fail unless it is under the guiding hand of Rod. However, Spring has spread beyond it’s core functionality and expecting the same level of buy-in from developers, and from Rod’s post referenced at the beginning of this post, it seems they are even trying to Manufacture buy-in.

At one time, the Spring team would have criticized the inability to move a ‘standard’ EJB from one app server to another, now they just expect you to deploy applications in their proprietary modules for their app server. They would have criticized the bloat of the implemented standards, and now if you want to use their web flow API, you have to include their Web MVC framework even if you are using JSF. I think this is a bit of a reach from the SpringSource folks. Just because I put my Dependency Injection egg in your basket, it doesn’t automatically mean I’m going to put my view technology and server choice eggs in there too.

4 thoughts on “Is Spring between the devil and the EJB?

  1. Well written article, you captured my thoughts, which were nourishing, when i read about spring app server.
    One of major advantage of Java, it is standards driven. But using spring, it’s making me spring geek, rather than java professional.
    I just read an article about java 7, and their support for java modules (JSr 277?). But spring embracing of OSGi, will create another rift b/w choice of technologies, which is bad for java.

  2. Thanks ashish, Java does have problems with regards to keeping a core set of technologies, especially since non-standard technologies evolve and develop much faster (Spring/EJB3.0, Hibernate/JPA etc..). Plus java developers also have their own ideas on how things should be done.
    Compare to, where even though different libraries may be used, the core / Winforms is the same.
    I would imagine this is also an issue when interviewing for jobs since 5 years Java could mean anything, while 5 years is targeting the core technology.

  3. I do not think that it is right to say:

    “Compare to, where even though different libraries may be used, the core / Winforms is the same.
    I would imagine this is also an issue when interviewing for jobs since 5 years Java could mean anything”

    Of course 5 years Java could mean anything, 5 years C# could also mean anything (between C# 3.0 and Java 1.6 I prefer C# but that is another story). This is why it is so easy for those Ruby guys to say that Ruby is better than Java: We do not call things by their name: I have never read an article saying Ruby on Rails is superior to Seam or AppFuse.

    The proper comparision would be between ASP.NET 3.5 and JSF 1.2 (because 2.0 is still not ready) and while Seam has made a lot to improve things for JSF the sad truth is that JSF is inferior precisely where it should be stronger: Standarization. Any component kit for ASP.NET will try to be compatible with the core Ajax library in ASP.NET ( and therefore will try to play well when combined with other component kits,if for no othere reason to avoid angrying microsoft and avoid getting ignored because they cause problems when combined with the official kit, but if you try to mix all this in one project you are in for a nightmare:

    I think what JSF needs is some kind of project the objective of making JSF from different author play together (and play with Seam/WebBeans). We need real functional standarization.

  4. I made this comment drawing from many years of working with Delphi, a platform which had many different component sets. However, those components were used within the same kind of core application code. A component for GWT is wholly different than a JSF component, which is different again from a Wicket Style component. Compare this to the .NET market where it is more like having multiple vendors producing JSF components.

    I agree that there is some missing standardization there and this could be down to the way the standards bodies work. When Microsoft developed .NET and the component libraries, it was easy to spot flaws in the design at implementation time and go back and rectify them. With Java standards, the flaws don’t show up till the standard is set in stone, and in JSF’s case, the IDE and component developers are trying to get things working together, and multiple component libraries are trying to play nice together at run time. It is too late at that point to go and clarify the issues.

    Also, it’s interesting that it’s hard to use a JSF library without setting up additional web filters and so on in web.xml. I imagine that this dependency on external mechanisms outside the jsf framework causes some problems, inconsistencies and incompatibilities.