This post was first published in french on Ippon Technologies Blog. This version was automatically translated.
On December 10, 2009, after more than 3 years of work of the JCP, the Java Enterprise Edition 6 was released. This latest version finally brought a very promising dependency injection solution for light and elegant modern architecture: the CDI specification (Context and Dependency Injection) working with “managed beans” (POJOs managed by a lightweight container) and EJB 3.1.
A revolution? Not really, for 6 years the Spring Framework already proposed a solution of this type. Knowing that Spring Source (VMware) is an active member of the JCP and participated in developing some JSR, it is legitimate to ask why CDI reference implementation is not Spring? Is it an editor strategy mistake or a deliberate calculation to become the challenger of a standard which is very close in terms of simplicity and functionality?
Sorry for those who do not like flashbacks, but history is essential to understand the current situation.So let’s get back to Java Bronze Age : 1999.
The genesis of IoC containers and Java
The beginnings of J2EE in 1999 were somewhat disappointing. If the servlet and JSP specifications were promising and the concept of EJB rather good, the implementation of the latter was extremely heavy and cumbersome. Thus EJB did not meet the level of adoption expected by its designers and initiate the schism between the J2EE application “heavy” and “light” server.
However the need for a lightweight container to manage business or technical components was real and as there was no standard solution, private initiatives began to appear. The first was probably Apache Avalon (1999) who introduced these concepts well before 2004 and the seminal Martin Fowler article ( http://martinfowler.com/articles/injection.html ) on the subject. That same year, 2004, Rod Johnson and Juergen Hoeller published the famous “J2EE Development Without EJB” and Spring version 1.0 was born. This solution quickly met with great success and is still the flagship solution in this matter.
Web frameworks and their need for “managed beans”
Back in 1999 / 2000, the need for more sophisticated components than simple Java classes in terms of interoperability or life cycle, quickly felt for emerging Web frameworks. The Struts FormBean , released in 2000, is probably the first such solution. Craig R. McClanahan, Struts dad started in 2001 the JSR 127, which gave birth three years later to JSF 1.0, the first UI Framework to introduce explicitly the notion of “managed bean” which is now part of Java EE 6 and CDI.
Spring In turn, addressed this need from version 1.0 (2004) classes to make available to the web layer of beans in the container. All that should change later to Spring MVC would become a serious competitor to Struts in 2005.
The need for persistence and the arrival of ORMs
Another aspect missing EJB 1.X and 2.X was mistreated by EJB persistence. This concept of association object to a model of relational database (Object Relational Mapping), was not new and had already been explored with a lot of languages like Smalltalk.
In Java, many projects are trained to respond to this need for ORM. One example is JDO , iBatis or Toplink . But the major player in the field was undoubtedly Hibernate. Like Rod Johnson, Gavin King of Hibernate’s father is also a star as open source Java and the confrontation between two men and their disciples, failing to give them a good image, took a good part of the developer community from the moment Hibernate JBoss acquired by the end of 2003 made the choice of a much more ambitious than Spring to try to impose his tools …
EJB is dead, long live EJB!
It’s late 2003 that Sun formed the expert group about EJB 3. On this occasion, Gavin King Emmanuel Bernard prominent members joined the Hibernate project and participated in the JCP Expert Group EJB3. Their work began in mid 2004 and ended May 11, 2006.
This new version of EJB was a complete overhaul (which has in common with the version 2.1 that name) incorporating the concepts of dependency injection and AOP made popular by Spring. Neither Interface21 (the company that would become SpringSource end of 2007) or Rod Johnson (although a member of the JCP Following his work on the servlet specification 2.4) were not a member of the EJB3 expert group.
One of the major innovations of this new version was the specification JPA (Java Persistence API). This persistence API fully modeled Hibernate managed the feat even to extricate the EJB3 specification for it can be exploited directly in Java SE and lightweight frameworks like Spring.
Through its participation in the EJB3 expert group, has succeeded JBoss Hibernate Framework to promote its range of reference implementation of JPA and integrate it with a standard solution and alternative to Spring: EJB3. Great success, but half way was needed to seriously cons-carrer Spring.
Java EE 5, a new era for the JCP
Java EE 5 in which integrates EJB 3.0 marks a milestone in the overall approach of the JCP. An entity controlled by Sun now includes more individuals and companies from the Open Source world. The main consequence of this openness is the creation of implementations before specifications. So Hibernate was adapted as and when measured by JBoss to eventually become the reference implementation of EJB 1.0 and JBoss began work on the betas of EJB3 and JPA as of October 2004 (over a year and a half before the output specification).
These early versions allow JBoss to begin offering an alternative to Spring for use Hibernate. With the arrival of this new JBoss open hostilities in denouncing how Spring uses the Hibernate session and arguing that EJB3 will be so much better. For his part, Spring, Hibernate does not hesitate to show the finger when users come on the forums Framework Spring questions about LazyInitializationException explaining that it is the fault of Hibernate if exceptions occur. This is clearly not the purpose of this paper to take sides, but we can say that later aggression and bad faith on both sides did draw. We will see some of these passages of arms that do not really honor of the two camps here: http://houseofhaug.wordpress.com/2005/08/12/hibernate-hates-spring/ or there http:/ / blog.springsource.com/2007/11/09/a-response-to-ejb-3-and-spring-c …
On the merits, with 5 years of hindsight, we can still say without too much subjectivity as the attitude of JBoss that was rather offensive and defensive Spring. This report summarizes quite well the two companies to market Java technologies.
Anyway, it was obviously that Spring was by far a more mature and complete to cover the entire application stack from the front to the persistence through the business layer. EJB 3 is later filled the contract side business layer and persistence but its operations through a webapp was rather complicated by the difference between the life cycles of EJB3 and those servlets, not to mention the systematic use JNDI to interact with EJB3 Popuri was not the developer’s life easier. Gavin King had clearly made this big gap (although officially he claimed qu’EJB3 advantageously replaced Spring) in 2005 and decided to start making a new framework for the bridge.
Seam and was …
The basic Seam is quite a challenge, because the stated objective of the framework was to facilitate the integration of two standards mals world’s favorite Java: JSF and EJB. We already mentioned in the previous lines EJB3, but keep in mind that the EJB name was (and sometimes still is) associated with the calamity of versions 2.1 and earlier. So EJB3 has been slow to penetrate, handicapped by the fact that he shares the surname of his predecessors.
Regarding JSF (JavaServer Faces), for short, this specification includes highly innovative ideas (development of web interface components and event programming), but the version 1 was marred by some unfortunate biases and limitations that have been written incomprehensible waves of hate on a lot of blogs like the famous http://ptrthomas.wordpress.com/2009/05/15/jsf-sucks/ . Combining these failures in the natural resistance of any community change, as saying that JSF was greeted coolly by the majority of Java developers and even today the image of this technology is pretty much negative among developers who have ever used.
Nevertheless, a number of people decided that there was “good in JSF” and that could work to correct his faults without calling into question its fundamental principles. This was the case of Gavin King, who in 2005 devised a framework to facilitate the use of EJB3 with an application using JSF as presentation technology. JBoss Seam was born.
From the beginning of Seam (before version 1.0), King expands the scope of the Framework. The story does not really say how it happened or whether it was all planned from the outset, but one can guess that in trying to better control the JSF managed bean, it has extended support to Seam components defined as simple pojo more EJB and finally added support for the competing technology: Spring. Then noting the controversy surrounding the JSF and not willing to mortgage the success of her baby, he opened Seam front of other technologies such as simple JSP and then later, GWT, Wicket or Flex (for the latter, that Wicket is the community that extended to ensure this support Seam, JBoss was content to formally incorporate the framework).
The version of Seam 1.0 was released in July 2006 but two months before, in May 2006 as Redhat (which finally acquired JBoss in April) submit to the JCP standardization project under the name Seam Web Beans. This is the beginning of the famous JSR 299 which will eventually called out CDI in December 2009 as a novelty in Java EE 6.
From the start of the Expert Group, Gavin and his team began working on the reference implementation of CDI Sosu called Weld.
Meanwhile side at Spring …
During the years 2005 – 2009, SpringSource has worked on the launch of new products: application server based on Tomcat (tc Server), application server supporting OSGi technology (dm Server), development of a software fully AOP (Spring Roo), absorption of Groovy language and Grails Framework. Lots of things very interesting indeed, but for the Spring Framework, nothing very revolutionary.
In contrast, the discourse of Spring Source for JEE (J2EE they continue to call) does not move one iota. As if JEE 5 was never released. Proof of this is the keynote from Rod Johnson dated December 5, 2009 (5 days before the official release of Java EE 6) in which he continues to explain that JEE is complicated http://www.infoq.com/presentations/ Lessons Learned-from-Java-EE
The Rendez-missed by Spring
By unrolling the whole thing again we see a number of golden opportunities missed by SpringSource to overcome its status as de facto standard and become a standard at all. When designing EJB3 example, or when launching the CDF specification, it would have been easy to make as JBoss and come to “impose” Spring as implementation of the standard. Instead, Rod Johnson and his team were on a very defensive and a speech less and less credible devaluation of the standard JEE gradually as it became an alternative more and more real in Spring.
What follows is very subjective, but here are the points that I think has been lacking in Spring in order to play this one:
1. The late adoption of annotations
Spring waited version 2.5 in November 2007 to start using (and even partially) the annotations introduced in Java SE 5.0 in September 2004. Over 3 years to adopt the supplement to the pure XML configuration. I will get into debates XML vs. annotations, for me both are useful and have their use cases. Spring Framework is an open and willing to leave the choice to its users, they would adopt the annotations from version 2.0. The lack of annotation makes big projects Spring fairly complicated to understand by newcomers. Having separate configuration code is a bit like getting stuck with a piece of furniture in the timeline on the ceiling of the adjoining room not very practical.
2. The denial of EJB 3
The first version of Spring supports EJB3 is version 2.51 in early 2008. Earlier versions only support EJB 2.X Knowing that the first stable releases of EJB3 emerged during 2005, there is also a gap of three years to take into account a more important technology that is partially concurrent. When compared with the few months it took to integrate JBoss with a real support to Seam Spring, it is breathtaking.
3. Posture anti Stateful
A big difference between EJB3 / CDI and Spring is the existence of components in stateful EJB3. Without going into details, the approach allows stateful decorrelate the life cycle component of the application, allowing you to easily create different contexts such as context or background conversation in Business Seam. Spring provides roughly the same result but without stateful technology, yet the team has spent much time decrying the EJB3 approach to add value. Embarking on the obscure and clearly ideological debates when to give a clear indication of its strategy and its tools do not appear to be the best strategy either.
The strategy Spring?
One wonders if all the choices SpringSource contribute to a strategy and if it will stay out of JEE is a deliberate choice. There is an initial response to this question here: http://blog.springsource.com/2007/11/09/a-response-to-ejb-3-and-spring-c …
Basically to summarize this lengthy exchange, Spring did not wish to integrate into the JCP does not freeze its Framework. Indeed, given the pace of delivery of the new specifications (average 3 years), there is concern by focusing on the JCP no longer have control over their product and having to wait 3 years before to standardize new version does. The approach of JBoss Seam with Hibernate and shows that it is perfectly possible to play it both ways by normalizing a subset of the tool and with extensions that we had to move outside the specification. Seam 3.0 is a perfect example: the framework is a collection of plug-in ILC to reproduce what was Seam 2.x but on the basis of specification Commission. These modules comprising Seam 3 appear in theory be able to interact with any implementation of IFA and would therefore not specific to the reference implementation Weld.
Furthermore Java EE6 address this issue “slow” in the path specification by integrating now the concept of “profiles”. A profile is roughly is a set of technology and technology framework or implemented jointly to create a very specific application environment. Creating a new profile in Java EE6 occurs independently of the evolution of the Java EE specification, you can create in a few months and offer a new “profile”. The risk of “freezing” its framework for 3 or 4 years by integrating a Java EE disappears completely if we integrate it into the logic of “profiles”.
The Spring team clearly did not contemplate the things this way and merely stay on “standard is” without bothering to go further.
In fact it appears that in the Spring area seems to have no strategy or a strategy so very blurred. The best illustration of this to nearly the catastrophe is certainly of JSR 330 (@ inject)
Specifying @ Inject, panic or obstruction?
A quick reminder of facts: in May 2009 or 3 months before the release of JEE 6, Rod Johnson and Bob Lee (Google) challenge on the JCP specification Commission (started 3 years ago), the ordering too heavy and does not provide a simple dependency injection. They propose an alternative specification based on a simple set of annotations, including the famous @ Inject to standardize the Java dependency injection. Ideally, we obviously can not blame them: Gavin King has led his boat and drove a specification (too?) From complete even include a mechanism for event-dispatch messages among components. It is well beyond the injection light that frameworks like Spring or Guice Google offer.
Where the initiative of Rod Johnson and Bob Lee is frankly debatable is that it takes 3 months before the release date of Java EE 6. Where most of Java EE 6 specification took three years to walk. In addition, Google and Spring were free to join the expert group of IDUs in 2006 rather than a tumble Express specification at the time of delivery.
The result is a specification @ Inject poorly crafted, whose implementations may diverge and a delay of 3 months for JEE 6. We avoided the disaster of having two specs on dependency injection incompatible because the expert group of IDUs has agreed to take in account @ Inject Commission.
This episode could be considered at worst sabotage or at best as a panic reaction, is really not very glorious for Spring (and to a lesser extent Google) and has generally had the effect of discrediting the comments Rod Johnson negatives about Java EE 6.
Spring not an official standard and then?
Today, Spring is a de facto standard. Hundreds of thousands of developers around the world use this excellent Framework with great success.
Why worry about the standardization?
The first response is related to the history of Spring: This tool was created to compensate for a big flaw in the official standard and offer a real solution container lightweight components. Henceforth the standard is corrected, the purpose of the tool diminishes and although its popularity and quality are always a great choice, he returned to competition with an official equivalent solution, where it would could be that standard.
The second element relates to the governance of Spring. As we have seen VMware’s strategy is not very clear and now only half a dozen brilliant minds really contribute to this Framework. All this seems rather weak and from the moment an alternative is more universal, it seems reasonable to take an interest to avoid being captive to one company in this case, VmWare.
Taking the problem from the other end we may wonder about the reasons that could hold Spring to take this path of standardization. Frankly, apart from the enormous undertaking that must represent the animation of such a specification, I see only positives: the ousting of a competing solution, the rallying of people who do not choose Spring and reinsurance existing users. Of course, turning in Spring specification, the company took the risk that other competing implementations appear, but with the advance team of Rod Johnson, Spring would have kept the lead on this technology such as Hibernate is the implementation of JPA most used even if eclipse link is the reference implementation of JPA 2.0.
What future for Spring?
Of course, it is not about predicting the end of Spring. The Framework is well established and continuing to fulfill its mission successfully. However, there is always a bad sign when a tool like this is not chosen because it is the best solution but because taking another solution would cost too much in training and change management.
In any Java EE 6 and CDI have a long way to go to become popular. The hostility of a number of developers to productions of Redhat and the natural inertia of organizations to adopt new technology are its worst enemies. But it is nonetheless likely that this specification was a big success, the size of the community Seam is the best evidence.
On Spring if CDI manages to convince and begins to grow, the Framework of VMware may have to align this specification to become an implementation or risk being marginalized. In which case, it would lose some of its leadership and become a technology follower, in which he was one of the prime players.
If CDI is a dead letter, Spring will quietly continue his career as a leader in the world of lightweight containers in Java. But the betting is very risky, given the need for a battery of formal framework in Java, VMware is not at all sure of winning.
Thank you to Emmanuel Bernard (@ emmanuelbernard) who was kind enough to answer my few tweets on the genesis of EJB3.
The site picocontainer and especially its section “Inversion of Control History”: http://www.picocontainer.org/inversion-of-control-history.html
The site of the JCP:
Paris JUG Presentation JEE6 & Spring (08/12/09) by Antonio Goncalves and Michael Isvy: