Open Software Integrators is an open source professional services company that provides consulting,training, development and support. Andrew C. has posted 5 posts at DZone. You can read more from them at their website. View Full User Profile

Why Java EE Lost and Spring Won

10.10.2012
| 59582 views |
  • submit to reddit

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 won

JSF, 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 flops

It may be odd, declaring Spring the winner and Spring Webflow the loser, but this is really about application style.

The most promising development framework in this area was JBoss Seam, but to be honest, I never “got it.” I never “got it” on a fundamental level. To me the obvious next step wasn’t to revisit and remediate JSF; it was to make AJAX meet VB5 - to make it as easy to make standard multi-form applications as it had been with Visual Basic 5, only using a web/Javascript/Java platform.

Seam had some nice features, such as letting you “switch conversations” or “web transactions” while preserving them.  However, it was 10x more complicated than SpringMVC or Struts.  Meanwhile, web browser JavaScript engines were making big advances in performance and even compatibility. AJAX applications let you switch conversations as well, by opening another tab.

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 replacement

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

 

Published at DZone with permission of its author, Andrew C. Oliver. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Tom W-dzone replied on Thu, 2012/10/11 - 10:41am in response to: Shane Johnson

>If you really want to believe that Java EE 6 will do the job, you should learn what it is.

Sounds a bit snarky :) That's why I raised the concern, I want to learn...

>a) We are not talking about two incompatible models. You don't have to use @EJB anymore. You can use @Inject instead.

I'll give that a try and report back. So, then you advise continuing to use @Stateless or @Singleton beans for transactional work or do you advise a CDI approach? I suppose it depends, but I'd like your opinion on each approach.

b) That, and you no longer have to package the EJB in an EJB-JAR. It can be included with the web application (WAR).

I mention using an EAR, not a WAR- "ear/lib/". Can the ejb be in a regular jar in an EAR as well if we want it to stay in the EAR?

 

 

 

Shane Johnson replied on Thu, 2012/10/11 - 11:42am in response to: Tom W-dzone

My apologies. It was snarky ;)

I prefer to use @Stateless and then inject the EJB elsewhere. For a more sophisticated approach, I'll use an @Producer method with an @Qualifier annotation to expose the EJB. Then I would use @Inject with said @Qualifier to inject the EJB. This allows me to swtich from using an EJB to, for example, a web service client at will (so long as the implement the same interfaces). However, if I remember correctly, there may be a catch when you are trying to inject a remote EJB. Perhaps that is when @EJB is needed?

That being said, I admit this approach is likely more complex than it nees to be. I just find it to be elegant.

Regarding your second question, I'm not sure. I typically just add the EJB to my WAR either via a JAR or as one of the classes. I have generated EAR artifacts too. In some cases I left the EJB in its own JAR. There really isn't much of a difference between a normal JAR and an EJB JAR now. I use Maven though, so if there is a difference I haven't noticed it.

Liam Knox replied on Fri, 2012/10/12 - 6:10am in response to: Shane Johnson

I really dont understand. You are talking semantics rather than what is here now, what you trust and what does the job. I question @stateless, what does it mean? You are back not understanding local remote? Your back to fast data reader aka select * What is the problem/ how do you solve.,... oh i clearly need a remote stateless sessiin bean! Is c++ coming back in another level of madness

Piotr Kochanski replied on Fri, 2012/10/12 - 6:58am

"Why Java EE Lost and Spring won" - lame and ridiculous statement, kind of Linux vs. Windows and VI vs. Emacs.

Spring is popular only and only because Java EE exists. There are two sources of power of Java EE.

First one is that you can pick its elements as needed. You don't want EJB, ok, you don't even need to know that they exists if you prefer using Servlets, JSP. Don't like SOAP web services, the same story, go with JAX-RS stuff and never look back.

And Spring is using that aspect of Java EE, they've created EJB alternative (why not?) that works well with other Java EE specs on any application server. Java EE does not enforce any particular architecture, framework, etc. And this is good. People who are working for telcomes might know nothing on Servlets and JSP, instead they use JCA connectors that are able to talk to their wacko hardware.

The other source of Java EE power is that it is standard. Spring became a popular framework only becaus it was usable with any standard web containter. If Spring wasn't like that it would end up as a particular solution in one particular company, as it happens with many (sometimes very interesting) frameworks written in C/C++ or Python. 

So Spring a lot to owes Java EE and vice versa!!! Java EE is gaining thanks Spring. Speaking about losses and wins is more about creating one more usless flame war then actual discussion about when and where particular approch to programming is good or not.

 

Marcelo Melo replied on Wed, 2012/10/17 - 7:45am

So, you used to be JBoss's b**ch and now you're Spring's b**ch, I got it.

Patrik Dudits replied on Fri, 2012/10/19 - 4:20pm in response to: Tom W-dzone

Concerning your route a) thigs are not so dim as they appear to be:

  So, for isntance if I switch a CDI beanA to an EJB to make it transactional, all other beanBs that inject beanA now need to switch from @Inject to @EJB

 You can create a producer for your EJB. Other injection points need not to be changed.

 and that bean can no longer just live in ear/lib as a regular jar, it needs to be part of an ejb jar (as far as I know) 

Correct, that jar would need to live in ear as an module, not as library, but the jar itself need no special treatment.

Also note, that the fact, that EJB is not CDI managed does not mean CDI features are unavailable to it. @Inject, eventing, everything works just fine. I recommend reading Weld Reference instead of the tutorial, and checking out Adamin Bien's JavaEE Patterns for better examples of CDI usage.

Alex(JAlexoid) ... replied on Sun, 2012/10/21 - 2:31pm in response to: Andrew Oliver

You can prove these statements on jobtrends or any similar site.  
 Yet they do not reveal anything.  Spring is always bundled with Java EE. These two go hand in hand and will for the forceeable future. But then there is real application of those and Spring is niether winning nor loosing today.

Andrew Oliver replied on Sun, 2012/10/21 - 3:15pm in response to: Marcelo Melo

Childish infantile statement aside.  Over on my InfoWorld column I'm talking about how you can write everything in JavaScript if you want to and that I can even see the benefits of that.  I stand by that Spring won over JavaEE at the programming model level and that is unlikely to change (especially with a lackluster EE7 release).  I honestly don't exactly care what wins generally, but it is important to notice when something is winning so you can capitalize on it.

Bill Burke replied on Wed, 2012/10/24 - 8:57am in response to: Andrew Oliver

Andy, why not use JAX-RS, JTA, JPA, and Infinispan?  same thing... Then, when I realize that Big Data is horrible at queries, I can switch to RDBMS.

Grzegorz Grzybek replied on Thu, 2013/01/31 - 12:14am

And the latest news why JavaEE won: JSR107 progress and Java EE7...

Dominik Sienkiewicz replied on Fri, 2013/09/20 - 2:04pm

And I think that Spring was in addition to the JEE. It seems to me that Spring is not inherently competitive for JEE or rather its developments. What however is issue in JEE is release every 3 years. How they want to be on time? I think that many would be improved if the EE was released every year or at least parts of it. Spring 3.2 in December 2012 ... at the end of this year will be Spring 4. This is the power of Spring.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.