Rod Johnson ran some job listings comparisons between EJB and Spring on Indeed.com, a job listings aggregation website, and by interpreting their results draws a few conclusions related to the evolution of EJB and its future. He frames the discussion around EJB by focusing on session and message beans and acknowledges the value of JPA which, as a separate specification, "is based on modern technology, and is proving its value." Johnson first writes about the significance of job demand trends:
Job listings are a good indicator of the true adoption of technologies. They indicate whether or not companies are spending money, making it possible to distinguish substance from hype; they indicate the importance for developers of gaining and growing the relevant skills (an important element of technology perpetuation); and they provide a good guide to the safety for companies in adopting a particular technology.
Johnson then presents a chart which shows that, in November 2007, Spring surpassed EJB in terms of skills requirements for Java job listings. He finds this amazing given the considerable amount of existing EJB-based applications.
Johnson draws some personal satisfaction from observing these trends as he has been predicting since 2003 that EJB will lose its relevance due to deficiencies he described in his book about J2EE without EJB. Even the new improvements in EJB3.0, in his view, are not sufficient to deter these trends:
EJB 3.0 improves things somewhat, but it's still too little, too late: the DI capability is less than has proven to be needed for the real world; the interception API recognizes the need for a solution to cross-cutting concerns, but provides the least capable, clunkiest and most error-prone solution yet seen (something I've been meaning to blog on for a while); it's saddled with the baggage of backward compatibility with now irrelevant previous generation technologies; the full EJB contract (which is hundreds of pages longer than the "simplified programming model") dictates a complex runtime with excessive overhead; despite its syntax sugar, it fails to address a number of deficiencies in EJB such as startup actions, singletons and the obsolete threading model. Finally, it's effectively tied to an app server environment, at a time of changing infrastructure.
He then interprets what the decline of EJB means for the industry as a whole and for individual developers:
- It's not necessarily a rejection of standards–just a healthy rejection of standards that don't deliver results. As I've long argued, Java EE is more than EJB, and anyone who cares about the platform as a whole should be honest about the relevance and quality of the parts.
- With better technology, business objects become POJOs, dependence on specific component models diminishes and labels become less important.
- Moving away from EJB provides greater architectural flexibility, at a time when requirements are changing, through the rise of SOA and other forces, and companies are increasingly choosing lighter-weight deployment platforms.
Johnson concludes that "as the absolute numbers are still very high, EJB is not going to go away completely any time soon. But the trend lines clearly suggest that it is becoming legacy." An EJB skeptic, Rick Hightower also believes that EJB will still be around for some time but points out a possible concern with the way the comparison was constructed:
However, EJB is far from dead, isn't it? Is it really fair to compare a general purpose framework like Spring (i.e., Spring MVC, Spring WebFlow, Spring XXX) with a very focused framework like EJB? Relative comparisons are not very fair to established players as you can see by this graph comparing EJB3, Seam and Spring.
Ray Van Eperen also commented in regards to the need to consider the possible impact of other technologies:
...there is an obvious omission of technologies such as Seam, that combined with EJB 3.0 addresses many of the historic weaknesses of the EJB model as well as provides many of the same advantages as Spring (use of POJOs, IOC, etc.), and in my humble opinion, does it better than Spring (for instance almost purely annotation-based rather than XML). I'm not knocking Spring, I'm just saying that EJB3 combined with Seam and other technologies such as JSF provide a very viable alternative.
Given that a significant share of EJB-based applications rely on application servers that use proprietary implementations of the EJB specification, these trends probably also show an increased confidence among companies in leveraging open-source frameworks for their core Java enterprise component models. While these comparisons prove the significant momentum the Spring framework is gaining, do they also signal that the EJB model is at the brink of starting to lose its relevance?