Roger has posted 6 posts at DZone. View Full User Profile

The JEE wars are over - and Spring has won

01.27.2008
| 27806 views |
  • submit to reddit

I pose the question of whether the JSR manner of process has really been a good thing for the Java platform. I truly wonder on account I think some of the best Java software came into use and wide acceptance without the blessing (and presumed benefits) of a JSR process and any eventual official ratification.

Maybe it's a matter of the principal of meritocracy pitted against 
official certification.

Case in point - Spring Framework vs. JEE/EJB

JEE and EJB have been creatures of committee specifications. They were 
born that way - and were overhauled that way (even with the 
participation of some important innovators - but still a committee).

Spring Framework, on the other hand, is a free agent. It's success has 
rested on terms of its merit - not sanctioning or sponsorship of a 
committee backed by big vendors.

Sun devotes time and resources to implementing items - like Glassfish - that are 
creatures of the specification process. By all accounts they've done a 
nice job with Glassfish. Yet in sticking to this approach they miss 
out on a wider field of opportunity to engage in rampant innovation. 
The concept of a Java application server could be something far more 
fascinating than Glassfish - especially given we're 12 years into Java 
and some basic needs for the app server have still not been met.

The Spring Framework has not been so artificially hemmed in. Where ever it was sensed that there was a valuable need to be filled for 
server-side Java development, Spring Source has moved to address it.

To wit, let me close with this article reference - which gives an 
indication of just how far behind in the dust the officially 
sanctioned specification approach has been left:

Spring is the new Java EE version

The Spring phenomenon though, is too big to not end the article dwelling on it again. Spring will be integrated with OSGi during the remainder of 2007, Rod Johnson said in his talk on Spring 2.0. OSGi is a dynamic module system for Java, something that should have been part of Java from the beginning. Strangely, it is currently pervasive on the client side due to Eclipse (plugins), but not well known on the server side. The Spring-OSGi integration is likely to make it into OSGi standards. And as a testament to Spring's decoupled pieces-parts architecture, Spring itself is available as OSGi bundles.
Longer term, the Spring Framework is turning into the Spring Portfolio. There are integrations with JCA, CICS, and IMS. There's Spring Web Services, and Spring LDAP. Message-driven POJOs will become possible with Spring. Acegi, the leading enterprise-grade Java security framework, is becoming Spring Security. There's Spring Web Flow, which is just what it sounds like, again with POJOs. The role of Spring in SOA is being standardized with efforts such as the Service Component Architecture (SCA). A Spring IDE (implemented as plugins for Eclipse) which will support Spring development, including support for AOP, and Spring Web Flow, is in the works.
Published at DZone with permission of its author, Roger Voss.

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

Comments

ff aaa replied on Sun, 2008/01/27 - 10:34pm

i am sorry but this comment has more publicity than content. Spring is nice, granted (we use it in our projects, with love and hate), but it still is mereley a collection of a verbose ioc, a low level mvc framework and tons of good designed abstractions over other technology implementations like orm, jdbc, rmi.

Yes, EJB 2 is dead already, but with JEE 5 is pretty good IMHO. Take Seam, they use mostly JEE 5 technologies  and work pretty well without spring. Also There is nobody stopping people to mix and match technologies. As a result, Spring guys gained a lot of ground, and now they want to get some juice out of it with trainings, books, support and certification programs. and they have a right to do it, but war is far from over. 

Roger Voss replied on Sun, 2008/01/27 - 11:00pm in response to: ff aaa

It's over because JEE5/EJB3 has shown no sign of momentum of uptake.

No one doing greenfield is bothering to choose to do so on top of JEE technology anymore. Instead it is roll custom stacks on top of Tomcat/Spring and other sundry pieces. By front-ending with Apache web server, Tomcat can be multi-instanced - which provides a basis for doing multi-application side-by-side deployment with rigorous isolation. OSGi bundles provide a modularity solution of dynamically managed services, which lends to large scale, large team enterprise application development.

A technology effectively "dies" when it ceases to be chosen for the basis of greenfield projects.

 Spring Passes EJB in Job Listings - The JEE Monolith Is Breaking Up 

--RogerV 

"Let me get right to it by lobbing some grenades: I recognize two arch evils in the software universe – synchronous RPC and remoted interfaces of distributed objects."

ff aaa replied on Sun, 2008/01/27 - 11:33pm

well, are you comparing JEE versus Spring or EJB versus Spring? i think the whole comparison is badly flawed. Also even though i am not a supporter of heavy application servers, i believe they offer much better management-deploment solutions over tomcat.

Rick Hightower replied on Mon, 2008/01/28 - 12:38am

I agree with you about EJB3 but not JEE:

Here is an excerpt from a post I wrote 1.5 years ago:

Having endured building applications with EJB 2.x and Struts, using Spring and Hibernate was like a breath of fresh air. Development was easier and less time was spent working around the limitations of the platform.

J2EE has good ideas, which inspired a lot of additional ideas. This evolution led to innovative and productive practices outside of the JCP.

The JCP has had some very good JSRs, but you have to admit there have been some real stinkers.

EJB in general, except as a learning experience, is generally viewed as a failure. The real problem was not just EJB but the misapplications of EJB. This was widespread as it was promoted with the J2EE Blueprint, not to mention the misapplication of JTA, and more features of J2EE. Not to say that applications can't benefit from JTA and EJB, it's just that many, many Web applications don't need them.

EJB 3.0 is much better than EJB 2.x. If you compare EJB3 to an older version of EJB, EJB3 is a boon; however, if you compare EJB3 to Spring and Hibernate, it stinks.

The related OR (Object Relation) Persistent API does not have a criteria API specified; any persistent API that does not define a criteria API is not finished.

The AOP support in EJB3 is broken. EJB3 has a method interceptor, but no pointcuts. In addition, the method interceptors are declared and imported with class-level annotations. This effectively tightly couples the class to the method interceptors that decorate it (Can you smell the bad odor?).

Rod Johnson mentioned thess same problems about EJB3 Method Interceptors at a recent Java enterprise conference (in his talk "Are We There Yet") and went on to mention many limitations on the @Resource style of DI, the absence of FactoryBeans, post processors, Constructor Injection, lists/maps, and a lot of the features Spring developers know and love are just missing. The EJB3 JSR members did not look at any of the prior art in this space and created their own limited version of what was already available.

I've heard some call EJB3 a dumbed-down version of what is available by using Spring and Hibernate. "EJB3 is Spring and Hibernate's stupid cousin" is frequently echoed.

After three years of deliberation, the JCPs delivered EJB3, which is inferior to de facto standards. Many parts of EJB3 are a big step backward from Spring, and, to many, EJB3 is broken. As Bruce Tate says about EJB3: "Don't make me eat the elephant again."

It's not just the persistent API and the AOP support that's broken in EJB3, it's also the random use of annotations, another misguided effort. The idea of annotations is good. The implementation of the annotations ruins some of the principles of the POJO model; namely, it ties your Java classes through a compile-time dependency to the standard API you're using and to any value-add annotations the vendor supports. Now why would vendors like this approach? Hmmm...I wonder. (Hint: Follow the money!)

In that question lies the real problem with the JCP. The JCP is heavily influenced by vendors that have "business need(s) or corporate agenda(s)." Parts of the enterprise Java community is innovative, parts stink, but there are many parts.

http://jdj.sys-con.com/read/216307.htm

rick hightowercto of arcMindbloglinkedin

Will Hartung replied on Mon, 2008/01/28 - 3:10am

Man, nobody seems to get it. Can't see the forest for the trees.

Let's play a game where JCP didn't exist at all. No committees, no standards, just fast moving projects promoting the be all end all.

Do you know where we'd be as Java programmers? We'd be like the huge Python Enterprise community. 

The what? Exactly. No where. Zip. 

We'd be coding god knows what in god knows what.

You DO know there were Java application servers before J2EE, yes? They all did the same thing (notably transaction services), and they all did them differently.

All of those servers are essentially dead. Why are they dead? Because while Borland, BEA, Sun and IBM would have problems competing individually with Microsoft in the enterprise, Borland AND BEA AND SUN AND IBM combined turned out to be a force to be reckoned with and stopped Microsoft cold.

J2EE gave them the common lever to stand on. They no longer had to sell individual servers to clients, rather they can sell a technology and a solution, combined with an indvidual server. Imagine if you had SQL vs "MQL", because that's what the enterprise market is today. Now instead imagine bql, beaql, sunql, ibmql vs MQL.

Who would by an RDBMS today that doesn't talk SQL? It's insane. With many enterprises, it's almost as insane to have application servers that don't talk EJB. See, EJB servers are by design supposed to be compatible with each other. That's what that big thick document is for. That's what those committees are for, to help ensure that folks investment in EJB technology doesn't leave them high and dry when a new system comes out, or a vendor quits, or they want to buy another company and integrate.

Obviously, the world is imperfect. EJB doesn't have perfect interoperability among servers. But it's close. And today, Web Services are trumping the underlying protocols of Remote EJB (RMI over IIOP, JMS), but in truth the integrations are serviceable and doable. And WS are doing even better with interoperablity, thanx to the committees (OH! There's that bad word again) and the hard work of vendors wanting to interoperate. Sun and MS are doing Gods Work in the web service arena, because even MS knows that they have to interoperate, and WS's are the best way they can promote their technology and solutions, yet still integrate and compete. Today, a wizard on NetBeans can generate code that will talk to a server on .NET and vice a versa. That tooling is making great strides.

Now imagine the corollary. No single servlet spec. No EJB spec, no JMS spec, nothing. Just random technologies rocketing in random directions.

You'd basically have the dogs breakfast that the open source world is today. Projects written in everything from ASP to Zope. Lots of great little islands, but all forced apart because they have essentially nothing in common. Look at this site right now. A (I assume) Java based community site, but they use a PHP based forum server, with imperfect integration (they probably simply share a DB/LDAP at this point). No SSO, no common control panel, even the avatars didn't copy over.

Imagine this scenario "You should use Spring, it's great!" "Oh, yea, I would but I'm running QBerts Java Web Kit server -- it doesn't work with Spring. Spring only runs on a Jingo server." Where do you think Spring would be today in that world? It'd still be in Rods notebook, implemented at a few client sites. Because the Java world would be so fragmented it would make code sharing difficult.

And a fragmented Java would be a dead Java. May as well code in REALBasic or Delphi.

Basically I think you have it backwards. EJB is becoming the new Spring. In the end EJB may even look very much like Spring. It's readily adopting many techniques from the greater EJB space, we already saw that in JEE5, and we're seeing more of it in JEE6. But there's a key difference between EJB and Spring.

Spring has a single vendor. JEE has, what, a dozen, at least? Large and small vendors? Commercial and Open source?When multiple implementations of JEE appear, it's called "Adopting the standard". When that happens with Spring, it's called "Forking", because there is no standard. If there was, then you're back to that evil committee thing because the implementors need to cooperate. Implementors have different agendas, different goals, different resources. Then all of the compromising kicks in. All of those horrors folks lament about. All of those horrible, evil things that got Enterprise Java where it is today. In general, as a rule, folks like "adopting standards", WITH the compromises, WITH the committees, over "forking".

So, JEE 6 is coming. Just like JPA became the "new" Hibernate (warts and gaps and all), JEE 6 may become the new Spring. And be Springy enough that Spring itself will have little value.

I can see it now. "EJB is the new Spring". And EJB gets the last laugh. And suddenly all my EJB code from the past 7 years runs in a new "Spring" container, with a drag and drop from NetBeans and a deploy onto a stock Glassfish  5 minute download and install.

Imagine that.

Roger Voss replied on Mon, 2008/01/28 - 4:01am

Last gasp of the JEE/EJB dinosaurs flailing around after the comet struck. 

Rick Ross replied on Mon, 2008/01/28 - 7:16am in response to: Roger Voss

[quote=rv49649]Last gasp of the JEE/EJB dinosaurs flailing around after the comet struck.[/quote]

Ouch, Roger! That's a tough image to visualize first thing Monday morning before I've even had my coffee! LOL 

ff aaa replied on Mon, 2008/01/28 - 9:48am in response to: Roger Voss

[quote=rv49649]

Last gasp of the JEE/EJB dinosaurs flailing around after the comet struck. 

[/quote]

is that your counter answer? how about losing all your credibility?

Rick Hightower replied on Mon, 2008/01/28 - 11:51am in response to: Will Hartung

RE: JEE gave them the common lever to stand on...

BINGO! JCP is important (not perfect) but where would we be without it? Well put! Well put indeed.

EJB was not perfect, but even Rod was pro-EJB in his first book.

The world of JEE does well because we have the right balance of innovative open source projects and standards.

If EJB3 would have been better, would Spring market share for job demand be less?

I think the answer is probably yes. To what degree, I don't know. (I am still very pro-Spring and use it daily.)

Spring and Hibernate infused some life into JEE. The relationship is reciprocal.

 

rick hightowercto of arcMindbloglinkedin

Rick Hightower replied on Mon, 2008/01/28 - 11:53am in response to: Roger Voss

Last gasp of the JEE/EJB dinosaurs flailing around after the comet struck.

BOO! Come on. Tomcat is JEE. JMS is JEE. JTA is JEE. Don't throw the baby out with the bath.

 

rick hightowercto of arcMindbloglinkedin

JeffS replied on Mon, 2008/01/28 - 2:31pm


Seems to me that EJB is far from dead.  The 3.0 spec is a huge improvement over 2.x.  It embraces a pojo model, and uses annotations that help get rid of XML configuration hell.

And being a standard is a plus.  That ensures multi-vendor and multi-open source implementations, and users/customers can pick and choose, and won't be left high and dry by a dying/dead vendor.

 Spring is good.  But so is EJB 3.0 (along with the rest of the JEE spec).  And traditional app servers still have their place.  They give you everything immediately via a simple annotation or configuration, whereas the Spring approach requires more plugining in of various elelments and then lot's of XML config for the wiring.

Also, saying "EJB 3.0 is better than 2.1, but it still lacks feature X, Y, Z from Spring, therefore it sucks" is ridiculous.  For instance, one poster said EJB 3.0's AOP implentation is lacking when compared to Spring. 

 This is true, but who cares?  First, AOP usage is vastly overrated.  Some people are using it, but there are still lot's of developers out there that don't even know what AOP is, let alone use it.  Two, AOP is yet another programming paradigm that involves a decently sized learning curve.  People are still struggling with proper OOP design in real world situations, and adding AOP into that mix can seriously muddy the waters.  Finally, if you want to use AOP, you cans imply plugin AspectJ to EJB 3.0 or anything else.  You don't need Spring to use it. 

Anyway, sure EJB lacks in some of Spring's more advanced features, and yes JPA is a subset of full Hibernate.  But EJB/JPA still have what's needed for most situations, and it provides them in an easy to use and easy to implement fashion. 

 Also to be honest, though, the EJB/JPA committee should consider adopting a whole new name.  Really EJB 3.0 is so hugely different and such a huge improvement over the 2.x version, it should be called something diffent (maybe something like "JEE POJO Beans".  They should lose the bagage that the name "EJB" brings, especially considering the fact that Spring zealots diliberately try to confuse EJB 2.x with EJB 3.0, knowing full well the two are completely different and 3.0 is a huge, huge, massive improvement.

 Finally, Spring zealots should STFU with idiotic proclaimations that "JEE/EJB" is dead, and Spring has won".  Simple fact of the matter is, both are still hugely rellevant, both have plusses and minuses, and both will continue to be used in the foreseeable future.

Ewald Dieser replied on Tue, 2008/01/29 - 9:23am

Even if you don't like EJB (I do, EJB3 is nice), how can you say JSRs aren't necessary? See it that way, why are you able to run Spring web apps on any servlet container or application server? Because servlets are standardized. JSRs are evil? Then go and implement something like Hibernate without JDBC. Standardization is important. Spring, Hibernate, all the Java Web Frameworks are successful because they make heavy use of standardized APIs (JSRs).

Michael Bushe replied on Tue, 2008/01/29 - 9:11pm

Spring would not exist without the JCP.  I'll bet Sun buys SpringSource anyway.

Roger Voss replied on Wed, 2008/01/30 - 2:14am

What started out as a piece that makes a rudimentary observation (that the momentum of Spring Framework is surpassing JEE/EJB) has struck a nerve amongst some. There have been a lot of viewers of this piece, being one of the most active in the Java Zone lately. Of those that have registed a comment, the trend has been to take an opposition of one sort or another to my posting.

Well, there are quite a number of different directions I could go in attempting to respond to some of this, but I will just enumerate a few things that perhaps will lend clarity:

  • I do not work for Spring Source, have no affiliation with them, and do not derive any income from anything pertaining to the Spring Framework.
  • I concede there has been good work done through the JCP and that there are good JSRs that much benefit Java developers. The JDBC standard and servlet standard have been two of the biggies that most folks get the most mileage out of. It does indeed pay to have device driver like uniformity as like what JDBC provides to database access.

    None-the-less, these good things don't rule out the fact that a JSR process can also hem in and stifle innovation. Perhaps JEE/EJB at one time did enable the Java platform to mount a viable multi-vendor alternative to a Microsoft universe. But things do no remain constant forever. We should not fight today's battle in terms of yesterday's war. JEE/EJB proved to be flawed and the flaws were exposed by alternatives to JEE/EJB that were innovative outside of that specification (Hibernate first and then Spring Framework).
  • I'm having my dev teams build new generation distributed software systems, but JEE/EJB is not being used this time around. Let me clarify that. Sure we will be using technologies derived from JEE, but we're not using a JEE application server (and with no EJB container, then we're not using EJBs).

    Instead we are rolling a custom application server stack. This consist of: Linux OS at bedrock, Apache web server, Java 6 JRE, multi-instanced Tomcat 6 (as a means to achieve rigoroursly isolated, side-by-side deployment of applications), Spring Framework, BlazeDS, OSGi, ActiveMQ, and a host of other open source libraries and components (most of it Apache Foundation or under Apache license). There will be clustering and authentication/session management across the cluster for HA and load balancing.

    Lots of folks are doing it this way these days (or something very similar) - a lot of Java architects/developers are no longer choosing to build server-side software systems on a JEE application server substrate. Spring Framework is the empowerment mechanism that makes it possible to bypass using a JEE app server.
  • [quote=dzonelurker]When will those silly comparisons end? There is nothing comparable (overlapping) between JEE and Spring.The poor sod is a victim of the reckless Spring marketing campaign.[/quote]

    Though I hear or read this kind of sentiment all the time, I disagree with it as it is not a pragmatic view. If I can replace a JEE/EJB application server with a Tomcat/Spring stack, then these two are comparable and they do compete directly against each other. The fact that I (and countless others) have done this, as opposed to theorize about it, removes it from the fluff zone of marketing hype. BTW, since when is it reckless to promote one's business?

--RogerV

"Let me get right to it by lobbing some grenades: I recognize two arch evils in the software universe – synchronous RPC and remoted interfaces of distributed objects."

Fred Grott replied on Wed, 2008/01/30 - 9:07am in response to: ff aaa

 and what pretel is the hibernate orm integration in spring? Last I checked Hibernater was so stellar of ORM solution that it became part of a jsr spec in JavaEE..

 

Fred Grott(aka shareme) sometimes a JavaZone(JavaLobby) and EclipseZone contributor. Top visited blog on Jroller.com at: http://www.jroller.com/shareme/

Roger Voss replied on Wed, 2008/01/30 - 10:50am in response to: Fred Grott

[quote=fg82183]

 and what pretel is the hibernate orm integration in spring? Last I checked Hibernater was so stellar of ORM solution that it became part of a jsr spec in JavaEE..

[/quote] 

Spring supports integrating with Hibernate directly, of course, which has probably been the most popular ORM persistence choice to use with Spring. However, Spring these days supports using JPA. Then iBATIS is a rather popular choice too. But even the SpringJDBC template classes provide a more convenient abstraction point for doing JDBC.

 This all points out an advantage of going Spring - more choices in terms of persistence solutions. It is this kind of flexibility in all realms that gives rise to such enthusiasm amongst Spring users.

 --RogerV

"Let me get right to it by lobbing some grenades: I recognize two arch evils in the software universe – synchronous RPC and remoted interfaces of distributed objects."

Jeff Mutonho replied on Mon, 2008/02/11 - 9:47am in response to: Roger Voss

[quote=rv49649]
  • If I CAN replace a JEE/EJB application server with a Tomcat/Spring stack, then these two are comparable and they do compete directly against each other. The fact that I (and countless others) have done this, as opposed to theorize about it, removes it from the fluff zone of marketing hype. BTW, since when is it reckless to promote one's business?

--RogerV

[/quote]

 

And if you CANNOT  , what will be the argument then?

Roger Voss replied on Tue, 2008/02/12 - 3:34am in response to: Jeff Mutonho

Let's replace the phrase "can replace" with the past tense phrase "have replaced".

 IOW, this is already past accomplishment - there's nothing left to debate.

--RogerV 

"Let me get right to it by lobbing some grenades: I recognize two arch evils in the software universe – synchronous RPC and remoted interfaces of distributed objects."

Jeff Mutonho replied on Tue, 2008/02/12 - 6:45am in response to: Roger Voss

> IOW, this is already past accomplishment - there's nothing left to debate.

It's kind of  scary when one takes the position of being the only bearer of the truth  :). As you can see from the endless threads all over the internet , I beg to differ...there's still a lot to debate.

 Anyway , based on my experience in the corporate world , the big vendors are doing a great job in pushing JEE/EJB 3 for new projects ...but hey , since I don't have the numbers to back it up, I won't recklessly throw in the "counteless others"  phrase....

Roger Voss replied on Tue, 2008/02/12 - 5:38pm in response to: Jeff Mutonho

[quote]

> IOW, this is already past accomplishment - there's nothing left to debate.

It's kind of scary when one takes the position of being the only bearer of the truth :). As you can see from the endless threads all over the internet , I beg to differ...there's still a lot to debate.

[/quote]

Nah, am being taken too literally and ouside of conversational context yet again. The remark "there's nothing left to debate" was solely in reference to the matter that the development I oversee has successfully used Tomcat/Spring as an app server substrate for latest developed applications. That's been accomplished, it's no longer a theoretical possibility, so it has been removed from the matter of debate as to whether is feasible.

As to JEE continuing to have merit - debate away, by all means.

--RogerV

"Let me get right to it by lobbing some grenades: I recognize two arch evils in the software universe – synchronous RPC and remoted interfaces of distributed objects."

Passion Lab replied on Sun, 2012/09/02 - 3:48pm

I'll also add in a block for the valueForPathChanged method. Mostly this writing a research paper http://www.best-term-paper.biz/ grew out of my frustration with a software system that used a node based update system. I can't tell you how many "update causes ... in main tree" bugs I had to deal with as a result.

Lucifer Williams replied on Thu, 2012/11/15 - 4:44pm

Anyway, sure EJB lacks in some of Spring's more advanced computer training online features, and yes JPA is a subset of full Hibernate. But EJB/JPA still have what's needed for most situations, and it provides them in an easy to use and easy to implement fashion.

Comment viewing options

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