Women in Technology

Hear us Roar



Article:
  POJO Application Frameworks: Spring Vs. EJB 3.0
Subject:   Fatally Flawed Article
Date:   2005-08-05 10:28:46
From:   shadeltd
Response to: Fatally Flawed Article

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.


--Tim

Full Threads Newest First

Showing messages 1 through 3 of 3.

  • 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..