Women in Technology

Hear us Roar

  POJO Application Frameworks: Spring Vs. EJB 3.0
Subject:   Fatally Flawed Article
Date:   2005-07-12 00:32:15
From:   rodmac
Michael, your a analysis is, IMO, deeply flawed. I would characterise it as descending to the level of FUD. I'm afraid I consider this an expression of one person's bias rather than an objective comparison. Problems include:

  • You failed to disclose your employment with JBOSS until you were prompted by a post. The fact that the JBOSS group makes its money by supporting an application server--a piece of software which is not actually needed if you use the Spring framework--means that you and your employer have a material interest in ensuring that Spring does not become the de facto application programming model for enterprise Java. Failure to disclose this conflict of interest was unethical. Yes, even on the Internet.

  • You repeatedly refer to Spring as 'proprietary', when it is in fact distributed under the Apache open source license, one of the more liberal licenses in existence. Labelling an open source project as 'proprietary' is as clear an example of FUD as I have seen in many a day. Doing so while labelling yourself (in your bio blurb) as an 'avid open source supporter' is just rank hypocrisy.

  • You attempt to frighten people about Spring's viability and independence by asserting that it is tightly tied to Interface21. I note with amusement that the exact same argument could be raised about JBOSS as an application server. "Oooh, be careful! It is controlled by that JBOSS group, and you don't want to be tied to a company like THAT now, do you?" One wonders if Bill Burke would have been so happy to assist you with your article if he'd realised the argument was two-edged.

  • Your assertions about 'vendor lock-in' are factually incorrect, as any responsible investigation on your part would have shown. That configuration and deployment-specific code are tied to your platform is a truism. What people are concerned about is the business logic. "Is my configuration and deployment information entwined with my business logic so that my business components are tightly coupled to my current framework/platform?" Spring rates the same as EJB 3 here: ordinary business components have no tie whatsoever to the Spring framework.

  • Your most egregious error? You are comparing Spring, as it exists today, with EJB 3, as it may exist at some point in the future, and extolling the supposed benefits of the one over the other. It is simply amazing how much better incomplete alpha software is when compared to shipping software, isn't it? Especially if you 'conveniently' assume that said shipping software will not be enhanced in any way in the time before said vapourware actually comes to market.

    • This is an interesting topic, and an objective analysis would have been a nice contribution to the Java community. Unfortunately, that isnít what we have here. Your bias, and the overall tone of your article, are simply unacceptable. In the future, Michael, don't let your boss steer you into shilling for him under the guise of objective analysis.

Full Threads Newest First

Showing messages 1 through 11 of 11.

  • Fatally Flawed Article
    2005-07-12 00:56:43  MichaelYuan [View]

    Let me just say this:

    1. This article is an opinion. It is not labeled as an "objective study" from a research firm. This represents my own view on the Spring versus EJB 3 debate. However, I do not consider my employment at JBoss has anything to do with it. JBoss is not even the spec leader in EJB 3.0 -- for god's sake! I did not shill for JBoss proprietary technology (like JBoss AOP or Hibernate). I am talking about "standards" here.

    Plus, I did not attempt to disguise my employment at JBoss -- as the other poster found out, it is right there on my home page.

    2. "Proprietary" means "non-standard" in the context of this article. You can have open source but yet proprietary products. Yes, as you point out, JBoss also have proprietary open source products that would lock you into JBoss (just like Spring is locked into Int21). But I am talking about EJB 3.0 here -- not JBoss's specific extensions. So that argument does not apply.

    3. I gave Spring credit for pioneering DI. There is no question here. In fact, EJB 3 got many of its ideas from Spring. However, I am talking about the whole application's dependency on the framework here -- the integration piece. Spring ties you to a specific vendor. EJB 3.0 does not. That is a key point from the article.

    4. EJB 3.0 exists today and I have seen people use it in product.

    • Fatally Flawed Article
      2005-07-12 07:37:29  TS133T [View]

      I donít understand which standards we are talking about.

      All spring is an AOP and IOC framework. Once Sun standardizes them than we can talk about standards.

      • Fatally Flawed Article
        2005-07-12 10:05:10  MichaelYuan [View]

        Well, the point is that EJB 3.0 is a standard but Spring is not. So, instead of blaming me for pointing this out, I think the Spring community will be better served if someone can try to get Spring standardized in JCP -- just submit a JSR proposal and let the JCP community work it out!
        • Fatally Flawed Article
          2005-07-12 10:49:51  TS133T [View]

          Spring is not standard it is a integration tollkit (I dont even want to say framework because its not based on abstraction but contains implementations against abstraction such as AOP, JMX, JMS, EJB and ect) between standards.
          • Fatally Flawed Article
            2005-07-12 10:58:22  MichaelYuan [View]

            That is why Spring apps contain vendor-dependent integration code (and XML files). Why not make Spring a standard in JCP -- so that all vendors can implement portable integration "toolkits"? Java has a strong tradition to standardize interactions between "components".

            In fact, EJB 3 does some DI (integration) standardization already. Why not Spring?
            • Fatally Flawed Article
              2005-07-12 11:13:49  TS133T [View]

              "In fact, EJB 3 does some DI (integration) standardization already. Why not Spring?"

              If you annotations than Spring will be able to do the same thing.

              "That is why Spring apps contain vendor-dependent integration code (and XML files)"

              XML is unavoidable if you want to avoid hardcoding (but again Spring doesnt force you to use XML for DI, XML is just one popular way of doing DI in Spring).

              The other alternative is to use annotations but again its kind of hardcoding since annotations are part of source code.

              "Why not make Spring a standard in JCP -- so that all vendors can implement portable integration "toolkits"? Java has a strong tradition to standardize interactions between "components"."

              Personally I donít see enough abstraction in Spring to be worth standardizing. I believe Sun thinks the same.
              • Fatally Flawed Article
                2006-06-22 06:22:24  _a [View]

                I don't understand anything in Java. I'm a Cobol programmer.
    • Fatally Flawed Article
      2005-08-05 10:28:46  shadeltd [View]

      First, let's set up some vocabulary.

      Standard - "regularly and widely used" (http://wordnet.princeton.edu/perl/webwn)

      Proprietary - "Something proprietary is something exclusively owned by someone, often with connotations that it is exclusive and cannot be used by other parties without negotiations." (en.wikipedia.org/wiki/Proprietary)

      These are appropriate definitions of some key words you've used in your article. Instead of saying Spring is "non-standard", you should say Spring doesn't have a JSR. When you use "non-standard" in a way that violates its basic meaning, you give a false impression of reality. By your use of "non-standard", Struts and Hibernate (and even Shale) would be out of the running when they clearly are "regularly and widely used". Spring is standard as well, though like the others, it doesn't have a JSR.

      As for proprietary, consider the nuance that this word holds, "connotations that it is exclusive and cannot be used by other parties without negotiations". Most proprietary APIs by vendors like BEA require "negotiations" in the form of payment, and are therefore not open to use by all. There are no such exclusive restrictions on Spring. In fact, most code that uses Spring for DI can throw Spring out entirely and substitute it for another service that performs creation and relationship management. Spring was intentially written so that your code *did not* rely on it. I've demonstrated this several times to people using real code. So in the sense that proprietary can "lock you into" something, Spring doesn't fit the bill there either. Your code can be wired up with your own home brewed thing or with a competing product. No lock in.

      Your use of "non-standard" and "proprietary" isn't a fair representation of Spring. So instead of casting Spring in the "it's evil because it doesn't have a JSR" corner, let the other points of your article stand out to show why you feel EJB 3 is a better solution. You have a valid point of view, and you've got compelling examples. Keeping your nuances straight will help you stay out of the emotional argument and write a more convincing article next time around.

      Missing a JSR isn't that big of a deal, I use stuff without JSRs all the time, so your focus there is misapplied. Your points under Service Integration, Flexibility in Service Assembly, and XML Versus Annotation offer the substance of your argument. While I don't share your views, I think all well thought out opinions should be discussed.

      Thanks for listening.

      • Fatally Flawed Article
        2006-01-17 19:11:14  javid [View]

        "Instead of saying Spring is "non-standard", you should say Spring doesn't have a JSR."

        Since we're providing all of these lexical clarifications, let's be more precise. There are two types of standards: de facto standards (standards based on widespread use throughout an industry) and de jure standards (standards that are created by a body or committee). When most people refer to something as being a standard, it is implied that it is a de jure standard. If it is a de facto standard, one usually clarifies. That is why you hear "de facto" much more often than "de jure". EJB 3.0 is a standard (de jure) and Spring is not (de jure or de facto). Spring may currently be in more use, but anybody who claims that it is a standard in any shape or form is smoking some serious crack. Ask any consultant who has worked at many different client sites over the last several years to tell you what percentage of projects are using Spring. More interestingly ask them what percentage of projects are using EJB 2.1 (or previous) technologies.

        "In fact, most code that uses Spring for DI can throw Spring out entirely and substitute it for another service that performs creation and relationship management. Spring was intentially written so that your code *did not* rely on it."

        Sorry, but that is a load of crap. Anybody who has used Spring for anything more than plain-vanilla DI can tell you that. If I'm using JDBC template, I'm relying on Spring. If I'm using the DAO support, I'm relying on Spring. If I'm using programmatic transaction management, I'm relying on Spring. If I'm using HibernateTemplate, I'm relying on Spring... I could go on. If you go with EJB 3.0, you are coding to a standard, and you can switch between vendors without rewriting application code. Your comment is just flat out false.

        "Missing a JSR isn't that big of a deal, I use stuff without JSRs all the time"

        I think it is. This is one of this biggest concerns that many of the clients that I work for have. Yes, developers have the leverage to choose libraries and APIs that they use, but way too often, the decision about the overall infrastructure, architecture, or application server is made higher up the chain. When those higher-ups make decisions, they want to know if they're going with standards, and many times it can be a make-it-or-break-it point. I'm not judging whether this is good or bad, but just pointing out the reality.

        It seems like quite a few Spring lovers have bashed this article, but I found it to be very informative. I've used both technologies on production systems, and I absolutely agree with most of the points. I'd like to read some opposition to the article that has some substance. At least talk about one of the technical issues that Mr. Yuan brings up if you're going to bash his article. Annotations are simpler than gobs of XML. Spring can turn into a maintenance nightmare. EJB 3.0 is a standard, and Spring isn't. And no, I don't work for JBoss.
        • Fatally Flawed Article
          2006-02-10 22:05:55  frankelliott [View]

          Annotations require one to rewrite or modify source code just to do dependency injection. This makes annotations an intrusive technology; this means it is incompatible with legacy code.

          As someone who has a Ph.D. in scientific computing and who uses it every day to do datamining and to author statistical algorithms, I find dependency injection very useful in Java numerics code because most of the algorithm can only be re-used if reconfiguration of the data flow is easy. I'm not about rewrite my functioning, optimized legacy code unnecessarily. I'm using Spring for ioc and forgetting about EJB; I'll leave that to masochistic software engineers.
          • Fatally Flawed Article
            2006-02-22 07:44:02  steve--o [View]

            did you not read the sentence in the article which points out EJB3.0 supports XML configuration to override annotations for legacy code?.. so your point is meaningless..