billburke java, javaee, spring

The past 1-2 years since the release of Java EE 6, you’ve seen a lot of articles like this latest on TSS that talk about the niceities of Java EE 6’s component model over Spring and how Spring is now legacy. Yup legacy. Who would have thought it? (other than me of course 😉 ) I remember internal JBoss emails 4-5 years ago arguing whether we should give up on promoting Java EE as a component model (aka on EJB) and just concede to Spring. Now, 4-5 years later, Java EE 6 has answered the challenge and is a viable, rich, integration technology. So what happened?

Spring always depended on Java EE

Spring was and has always been a wrapper over core middleware infrastructure: ORM, Transactions, Messaging, HTTP. It always depended core Java EE specs like JPA, JTA, JMS, and Servlet. So, since you couldn’t deploy a Spring app without at least one of these core technologies/specifications, Java EE stayed in users minds. There was always the opportunity that Java EE could get its act together in component model development. While Rod Johnson always tried to position Spring as a Java EE alternative and JBoss killer, the Spring “platform” was never a true alternative to Java EE and JBoss, and in fact, couldn’t really exist without it. IMO, this was a huge missed opportunity for the Spring folks.

Being the anti-Romney doesn’t work in the long run

J2EE was a machine with a huge massive install base. A machine with a massive amount of money invested into it. Java EE was its own market. While Rod positioned himself over and over as the alternative to Java EE did he really think that this massive machine wouldn’t respond to the challenge? While there are a lot of radical technology enthusiasts out there, the core Java constituency is pretty much moderate. They are slow to adopt and tend to wait to see who is going to win the war over a long time. Spring could not replace Java EE because technology wise, they were dependent on it. All Java EE had to do was improve its component API message to the people, outspend Spring, and win over it in the long run.

Annotations were a game changer

The first thing that happened to shake Spring was the introduction of annotations in Java 5. Annotations were a game changer. Annotations were the opportunity to introduce mini-DSLs and pluggable keywords into Java. Java EE 5 grabbed this opportunity with a huge facelift and refactoring of EJB and the introduction of JPA. Basically, this was a standardization of Hibernate and its integration into EJB. Complex EJB 2.x XML was replaced by few new Java keywords (well, annotations). Simplicity ruled the day. Middleware started to look more and more like a language feature rather than something hacked together via XML. When annotations came out, I remember the Spring folks writing multiple blogs and forum posts about how evil they were. IMO, they were just terrified of this new technology as it made much of Spring 2.x obsolete, and, well, much of Spring more complicated than Java EE 5.

CDI closed API hole



Thank you Gavin and the Seam folks. CDI and Java EE 5 pretty much closed the technology gap. Not only did they fill the integration holes that Spring exposed, they innovated far beyond what Spring had and created something new. Beyond core IoC and DI, CDI’s event model was truly innovative and cool.

App Servers got their act together

Application server started to get their act together with regards to boot time. It started with Glassfish and ended with JBoss 7. Both of which can boot in a matter of seconds. The whole Spring complaint that you needed Spring to mock out and test your code because app-servers started so slow was moot.

Arquillian made a mock of mocks

The final game changer was Arquillian. One huge advantage Spring had was a unit testing story. They gave you the ability to mock out core services like transactions and allow you to test application code outside of the application server. This is huge for continuation integration and automated builds as well. Combined with the fast boot times of JBoss 7 and Glassfish, you no longer have to hope your mocks will work when you actually run it in its real environment. Arquillian allows you to run your unit tests in a real environment with real transactions, etc. Personally I always despised mocks because they didn’t test in the environment you were going to run in. I thought they were pointless and to this day, I refuse to use this testing pattern.

Anyways, in retrospect, I’m glad Rod and company were able to cash out with the VMWare acquisition before Java EE was able to regain its dominance. SpringSource pushed Java EE to innovate and for that I’m very grateful. For Java EE, it was either evolve or die. They evolved, now its time for Spring to die.