Why Java EE Lost and Spring Won
Curator's note: Andy is the CEO of OSI (Open Software Integrators). He's a forward-thinker and exceptional blogger. He will be writing regularly on DZone, so I hope you enjoy his thoughts as much as we do.
I hate to disappoint my former colleagues at JBoss, who are still keeping up the good fight to promote Java EE as a programming model, but they have lost. Not only have they lost the present, but the future doesn’t look bright. Java EE itself will survive, but it long ago lost the programming model war.
As early as 2005, most of the customers I worked with at JBoss were writing their applications using the Spring Framework. I was of course “on message,” and explaining about “standards” and whatever, but not even I was buying it.
There are several trends that have caused/supported this, and also a general structural problem.
Real AJAX wonJSF, MyFaces, etc. all started with the premise that sticking with the general Web 1.0 model of redrawing the page, but adding a sprinkling of links, was a good thing. However, we saw an explosion of “RESTful web services” and JSON on the backend with JQuery and HTML on the front end. Some of this was underestimating Internet users. I mean, the dumb sods could never adjust to not having the trusty back button as their main means of navigation through an application, right?
No. Users aren’t stupid. As popular applications like Gmail and Facebook, among others, brought users to an AJAXy world, users adapted their behavior. They also adapted their expectations: seemingly instantaneous response times became a practical requirement for many applications.
As AJAX won, so did SpringMVC, RESTful web services using JSON and general “statelessness.” The state-heavy, complex, session replication post-render-post-render method of application development lost.
Seam / Spring Webflow are flopsIt may be odd, declaring Spring the winner and Spring Webflow the loser, but this is really about application style.
This “state management” ala JBPM that Seam offered was laborious and sometimes a bit inflexible. It was like forcing a gopher model on to the free-linking HTML model. Spring WebFlow is basically the same animal as Seam. If JSF and Faces are the anchor on Seam, Spring Webflow has Dojo, aka the AJAX framework everyone wishes they could replace with JQuery.
Seam was made “a standard” in the Java EE “WebBeans” spec and then it became Weld and Java EE’s CDI spec. However, it is still all about server-managed state. Server-managed state began as a workaround for browsers that couldn’t hold state, where each page was re-rendered and cut from whole cloth. Later, with XMLHttpRequest/AJAX, browsers could manage state, but server-managed state was still used because of how much simpler it was to code (until you have a lot of it and the server crashes). Server-managed state has become a monster and complexity is being manufactured.
CDI as a Spring replacementVictory was declared when JavaEE managed to create annotations (CDI) mimicking most of the core Spring annotations framework. However, @Inject simply isn’t enough anymore. As the “high rollers” in the “Enterprise Java” world move on to “Big Data” and “NoSQL” databases and then move to the cloud, we need something a whole lot better than JPA. Spring Data is the future of Java persistence. It unifies the model of NoSQL and RDBMS databases.
Advocates of JavaEE will point out that it had annotations when Rod Johnson and Co. were still running around telling people that they liked XML but just didn’t know it. However, Spring adopted JPA annotations with Hibernate and then for the core framework around 2006. JavaEE annotations were still tied to EJB3 and later Seam. This container-oriented design gives you way more bloat than you need per minor Java Bean that you want injected.
What does CDI offer? Well, that Spring has a compatible implementation, but so what? Spring runs on all of the profiles “CDI” gives you access to. Sure, you might use the new annotations for new stuff, why not? But then CDI is the access point to Spring not the gateway to making you use application servers like JBoss or WebSphere.
And now for our show
So we end up with another 3 year cycle of Java EE playing catch up. Sure it will come up with another “standard” which requires proprietary vendor extensions to run efficiently -- but really was the JCP ever REALLY a standards board. Clearly most of the energy and drive (nearly all of the new ideas and most of the actual work) is still coming from JBoss (since JavaEE) and then Oracle and IBM delay while they figure out how to get their product to support it and then finally “agree” with some “compromises.” Meanwhile the market moves on and I certainly don’t want to wait 3 more years for a standard Java programming model for NoSQL or BigData, created by the same process that brought us EJB and CMP. Especially not when the “everyman” can participate today in an open source project.
And therein lies the structural problem. It is one thing for all the vendors to get together and bless protocols and agree on how their transaction managers will be compatible or low level tie-in SPIs, but the market really doesn’t wait for the programming APIs. The three or four layers of abstraction and corruption just take too long and create things, which look like an ugly JCP factory, to create the locator to create the factory to locate the singleton style pattern that we’ve all come to love.
Move on, JavaEE. Give up on trying to dictate the programming model and focus on the SPIs that you’re actually not half bad at.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)