Back in 2004 JBoss had a tough decision to make. Should we keep Hibernate proprietary and under our sole control? Or should we bring it to a standards body? You know the decision we made. I think Spring and Interface 21 are at a similar crossroads, whether they know it or not. I’d like to call on Interface 21 to bring core Spring IoC to EE 6. Here’s why its a win-win situation for everybody.
Better business for Interface 21
I personally think that the main reason I21 hasn’t thought about standardizing Spring is because they are worried it will hurt their business. We had the exact similar fear with Hibernate. What would happen if we standardized Hibernate and gave the opportunity to vendors like Oracle and BEA to enter the ORM space and threaten our growing strangle hold on ORM frameworks? The reality of the situation was that there was a shrinking, but still very large, set of users out there still using CMP. Many of these organizations were married to standards and wouldn’t go proprietary, even though Hibernate was open source. What ended up happening was that when we brought Hibernate to the EJB 3.0 and JPA specification, Hibernate was recognized immediately as a migration path to EE 5. Hibernate downloads skyrocketed along with Hibernate related business. I just know that Spring and Interface 21 would notice similar gains if they aligned with EE 6.
The Spring community will probably scoff at any suggestion that the EJB user base is still large enough to make any impact on things, but this is just not the case. Yes, Spring has a large community, but EE 5 stopped much of the bleeding and breathed new life into the EJB specification. I know this because I’ve been out there. There’s also these compelling facts about EJB 3 momentum that I posted on a TSS thread back in June.
Better for the Spring community
Let’s face it, Spring is not a kernel. It has no deployment model. It is dependent on bootstrapping itself through the WAR init process, manually, or by proprietary app server specific init classes. It has no classloader scoping, delegating it to the application server it is running in. The Spring guys know this is a weakness of theirs, which is why they are so keen to align themselves with OSGi. They desperately need a standardized kernel to build their own stack. If Spring was brought to EE 6, they would get this deployment model they so thirst for. Not only this, but it would be even easier, more consistent, and simpler to package and deploy Spring components within other application servers like what we do with the JBoss Spring Deployer. The Spring community would also get the benefit of mixing and matching Spring technology with EE component models.
Now, a bit more touchy non-technical subject is the idea that Spring is controlled by one vendor. Yes, its open source, but, IMO, JBoss history proves that a vendor can maintain tight control over its space even if there is defection and forking. Way back in the day, people also complained of the stranglehold Marc Fleury had on JBoss. The thing is, I thought our users were isolated from any real or imagined evil we might inflict on the open source Java community because we were standards base. This isn’t so with Spring. Spring is now VC funded which means its founders and investors are looking for an exit strategy and payday event. There were recent rumors of acquisition we heard as well before they announced this funding. Yes, this sounds a lot like FUD from me, but it is just the plain reality of the software business. Having Spring standardized would isolate the Spring community from the mess of any acquisition, IPO, founder exit, or going out of business fire sale. Any real or imagined mess 😉
Better for Java EE
Although EE 5 added some IoC capabilities, its still both verbose and incomplete. For instance, you cannot define graphs of pojos within XML and inject it into an EE components. This limits EE to having to solely work with primitives when doing configuration. Not very flexible. Beyond technical reasons, having Spring standardized would make EE 6 a compelling platform to migrate to just like annotations and Hibernate standardization made EE 5 exciting. Bringing the weight of the Spring community into EE would greatly strengthen and unify the Java enterprise space.
Unification
Before EE 5, you had division in the Java ORM world. You had the CMP crowd: big, but legacy. The JDO crowd: noisy, but irrelevant. And the Hibernate crowd: large, de facto, but proprietary. What JPA did was get everybody together and start showing a unified path and vision for the Java ORM space. I think Spring and EJB are in a very similar situation and we would get similar benefit of joining them.
So Rod, Bill Shannon this is good for everybody, so lets get it done.
Sep 04, 2007 @ 09:58:00
I strongly discourage to incorporate spring in to JEE and make it standard! Spring is in wide parts overrated. Look at their JNDI API. And what ist IoC? Hm, down to the core it is Gang of 4 patterns and common knowledge framework design with a new name…I thing spring is hype like it was struts 1. The later is long superceded.
I guess JEE 6 and further versions will be sufficient to form a *basic infrastructur framework* And I like the idea to have possibility to stack different convenience Frameworks (like spring) ontop of a basic infrastructure framework like JEE or OSGI.
BTW. OSGI and spring – I think if you let the OSGI guy do their job and look on what the plan to do then spring won’t be necessary for OSGI development. It wouldn’t even add a level of convenience…Sorry, this is my personal very emotinal view.
[digital:meditation] » Move spring to “standard” Java?
Sep 04, 2007 @ 10:56:15
Devylon » Standardize Spring in JEE6
Sep 04, 2007 @ 13:25:32
Sep 04, 2007 @ 14:25:11
Interesting entry Bill.
You are quite the diplomat. Must be the 10 years older thing, or the money 🙂
In thinking back, we went to EJB3 because it was the right thing to do, I don’t think there ever was a doubt that a standards status would greatly increase the adoption of HB. I do remember (well somewhat) a very lively discussion in Amsterdam around way too many pints of beer, even Bob Bickel was arguing with Gavin that it was the right thing to do. I want to say that this was just pre-EJB3 in 04.
It was the right thing to do as POJO programming turned out to be suitable for EE, not just SE. From my vendor perspective what Spring did was to validate the pojo programming model back in 04. It needed to be non-standard as the standard was non-pojo (do you remember the discussion about home interfaces?). The people who were adopting pojo were saying “we like IoC and AOP”.
If you think about it no-one really “owns” POJO development. The tags and wrapper classes don’t benefit from being proprietary. Spring was a proprietary EE4-EE5 bridge, and was marketed as such by I21 in the days,(“easiest migration path to EJB3!”) they probably made the calculation that people would taste Spring and stay on it. The risk was of course that Spring would be a point solution in time whose “raison d’etre” disappeared as the standards embraced POJO development.
So now, I21 goes for the proprietary card? But once you are at EE5, EE6 is a natural path. The spec is growing by itself. If a vendor decides to go against the standard then embracing a forking path may be worth it but this logic makes sense for “small players”.
From a acquisition stand point, a fork of the standard would mean a total anti-JCP stance. Sure it is OK, even recommended, for a small startup to say “standard suck”. But for an Oracle or an IBM it would be a fork of the JCP. I don’t think it is in their interest. Therefore, a standards patina would increase their changes for an exit.
I know how I would play that one, but we already crossed that bridge as you recount in this post 🙂
Hope you are doing well,
marcf
Sep 04, 2007 @ 16:15:11
Good argument, Bill. The reality is that Spring cannot afford to standardize without a major, non-OSS vendor coming out and giving their development model the vote of confidence that comes with a ‘standardizing’ on the Spring model. By this, i mean that Oracle and/or BEA will have to stipulate that their consultants are beginning to actively switch customers from EJB to Spring on their app server.
Of course, this is happening here-and-there, but until there is a major vendor that says that their customers have found Spring to be superior to the corresponding JEE technology, Spring is left with a shoot-the-moon strategy whereby they have to achieve all of the revenue opportunities without sharing that with other consultants.
You know better than I about how much scaling is needed for a Java/OSS start-up to be a contender in corporate IT. If Spring were to standardize without an app server vendor saying they are going the Spring route, they may become like another JSF framework. My hunch is though, that BEA and perhaps Oracle are looking for the right moment to make the switch.
How else are they going to compete with JBoss and Glassfish? On existing deployments, with existing customers, they are o.k., but I can’t think of a single reason to go with WebLogic, WebSphere (abstaining Geronimo), or Oracle on a new JEE 5 project. Spring is the only answer for differentiation, and if that becomes standardized, it would be a real competitive front to see who could implement more effectively.
Sep 04, 2007 @ 19:41:08
Hi Bill,
nice comparison and definitely some interesting points you made. IMO it makes sense to go Java EE 6 with Spring Core, but I do not know if i21 is willing to invest this lot of time into the slow and time consuming JCR/JCP.
i21 is already part in the Java EE 6 specification, so they will influence it one way or another. We will see how far this will go.
Sep 05, 2007 @ 01:16:51
Not the first time I’ve said this…but maybe the first time I’ve said it in awhile publicly. The JCP process is still bogus and not a “standards” body nor are its “standards” “open” except in the Maoist sense of “land reform” having anything to do with land or “Cultural Revolution” being about improving culture. Why should Spring which has an open development model join that dastardly thing and kowtow to IBM and Sun? I think EJB3 is great but when you tied “EJB” to it you basically poked holes in the yacht and sank it. You might as well have called it “DONTUSETHISITSUCKS” and probably it might have had more appeal frankly. Frankly, I think Interface21 is doing the right thing by steering clear of the Java Communist Party and letting Sun keep its NDA/Proprietary TCKs and closed process. Viva libre Spring!
Sep 05, 2007 @ 13:14:58
Whatever its bad points, I think the JCP has done a pretty good. As usual Andy, you are so full of complaints, but don’t provide any alternatives. And, BTW, exactly what JSRs have you ever participated in? This big vendor conspiracy theory you have just doesn’t exist. Makes good print, but is a myth.
As far as kowtowing to IBM and Sun, did Gavin and Hibernate kowtow to IBM and Sun when it joined? I don’t think so. IMO, I21 would have similar weight in EE 6.
Sep 07, 2007 @ 00:26:42
Bill, I’ve gone out of my way not to look at anything that would have bound me to any restrictive covenant that might prevent me from working on anything I might like… It has also been a good while since I’ve participated in proprietary software development.
To your point
* The JCP develops standards under NDA in a closed process
** stop doing that, make all transparent
* The TCKs are licensed after the fact under separate restrictive arrangements.
** require open source TCKs and make said trademark licenses open based on results with run rules (for example of an open reporting/run rule/etc see SPEC).
* Sun has a veto vote that no one else has
** remove it
* Individual participation requires liability exposure
** allow corporations/llcs with under $5m revenue to join for free
I always see a conspiracy where there is no transparency. If you go into a closet with someone else, I assume the worst :-)…especially where corporate entities are concerned :-)… If you’re hiding then why wouldn’t I?
Sep 07, 2007 @ 00:30:25
Oh and per “EJB”==SUCK rename JBoss EJB3: JBoss SOASuperCoolX and announce that it supports EJB3… Market SOASuperCoolX and note that while it supports EJB3….its better because it has XYZ (for instance service beans, MD POJOs, etc) and the SuperSOASauce. (I had said this some time ago…you thought I was just as crazy then 😉 )
Sep 07, 2007 @ 00:42:28
oh and aside from “must maintain compatibility with EJB3″…let SOASuperCoolX take on a life of its own, solicit feature requests outside of EJB3 aggressively, note it is “community developed/commercially supported”. Shake, stir and IMO since annotations are yummy and XML is yucky…in a few years you might think Spring is just about as important as Geronimo. (okay that last part might be overly optimistic, but who knows)
Sep 07, 2007 @ 12:22:54
Dude you’re brilliant. Absolutely brilliant. I can’t believe we didn’t think of that. I don’t like the JBoss SOASuperCoolX name/brand though. How about, I don’t know…. JBoss Seam? Yeah, that’s a cool name.
Sep 09, 2007 @ 04:29:45
Yeah JBoss Seam/WebBeans == smart. JBoss EJB3/EJB3 == not smart. Claiming that JBoss Seam == what I mentioned is misleading at best.
Sep 15, 2007 @ 19:01:08
Spring is not desperately looking for a deployment model. If it were that would mean Spring users are desperately looking for one and there is no indication this is the case.
It is my personal opinion Spring OSGi attempts to make OSGi integration in applications easier. As far as I can tell today – Spring OSGi is still early days – it doesn’t even offer a separate deployment model on top of ‘normal’ Spring.
There are actually compelling reasons for Spring NOT to be standardized. If you look at the growth of Spring since before 1.0 till today you’ll notice it’s a opportunist framework. Spring’s integration with APIs/frameworks/what-not has been added over time when it made sense and this often outside of the official Spring distribution.
Spring is also much wider than it is deep. That means: Spring adds small integration layers on top of many things – transactions, remote access, JNDI, JDBC, JMS, JMX, Servlet API, … – and the amount of these integration far outreaches the extend of any particular integration.
Spring is thus impossible to standardize. You can standardize dependency injection which has already happened to some extend and which Spring now supports. You can standardize other bits and pieces and Spring will always support these new standards. But you cannot standardize a opportunist framework itself.
Sep 15, 2007 @ 19:05:14
One additional comment: maybe you’re misreading the reasons why Interface21 participates in JSR 316.
Personally I believe they participate to make sure it’s done right this time over.
Sep 16, 2007 @ 03:40:35
Revue de Presse Xebia par J2EE, Agilité et SOA : Le blog de Xebia France
Sep 17, 2007 @ 15:47:26
Sep 19, 2007 @ 11:14:57
You are looking at Spring as if it’s just an IOC container. After all that’s only a small part of Spring. Anyway, IOC capability in EE is in fact very good. It makes wiring the beans lot simpler as you said. Agreed. Let the EE6 specs ensure it. It will be a welcome move.
So it should be “Standardize IOC in EE6” and not as the title above. Because integrating Spring in EE does not make sense. That becomes obvious when we see get down to see what Spring really is and what it means to standardize it.
Is it something that adds new functionality? No. Or provide new features that EE does not already provide? No. Spring does nothing by itself. It provides abstractions. Wrappers for other commonly used tools, not implementations. Makes developing an application easy, not differently.
For example, if Spring could generate xml feeds it would make sense to pull it in. But no, all spring can do is create the bean that can generate the feeds, without you bothering about how. So how helpful for anyone if the EE specs says ‘you need to have the ability to generate the bean for generating feeds’?
So what would you take from Spring in to EE that’s not already in EE? AOP? alright. Ok, what else? Force application servers to support HibernateSupport? JUnit? Toplink? any n number of tools that keep coming? And tie users to SpringControllers? If so really, how? Are vendors supposed to update the app server for each and every versions of these tools? Would you release a new EE version everytime one of these tools have a incompatible or major API change?
So it simply means you just can’t standardize it. You can also see then Spring is nothing more than a composite of layers that uses different components. So again, does it means you are willing to support all the tools that will ever be released? And put then into EE? Because Spring would have, in the future. Please, go ahead then. It would be really great. It would also ensure that you can ‘protect’ user community from open source projects that are run by people who may start waiting for their payday events.
And you are comparing Spring with Hibernate. They are entirely different. Hibernate is a tool whereas Spring is not. Spring just does things in a particular way out of many possible ways. You can also do it using struts and pico container. So why not them?
Also what makes you feel Spring is looking desparetely to build their own kernel and build a stack without providing any services? Who would anyone want to do that just to implement an IOC container? Let’s not forget that basically Spring is a framework and does what ever you want by depending on other tools. Not by itself.
All Spring has done is by an excellent way of implementing a pattern. And has got much hype because of it. Can you point someone who likes Spring because it supports ORM tools or JUnit? No. All one gets in mind hearing about Spring is IOC. As with struts, Spring is going through it’s honey moon period.
And that’s where your interest lies. Cashing in on a company that’s enjoying a limelight.
It’s quite natural tomorrow Spring grows old and another better framework comes along. So why would you think if something happened to Spring it would leave the panic striken developers groping in the dark? You as talking as if the Spring team has an exclusive hold on IOC pattern itself. Lets not forget that there are alternatives to Spring too and many upcoming ones. All I see is just another attempt to get more $$ in the name of protecting the user community. As the trend is now, gobble up the fine matured open source work and make it closed source. But I guess that’s another topic.
Sep 19, 2007 @ 13:28:55
Spring User, if you read the first paragraph of this blog, I do say:
I’d like to call on Interface 21 to bring core Spring IoC to EE 6.
I say IoC explicitly. So I agree with you on that front…
What I want is an end to the EJB vs. Spring debate. If Spring IoC became a part of EE 6, then all EJB turns into is a set of pre-packaged idioms. Lifecycle (instance per request, session, singleton) and cross cutting concerns (tx, security, etc…). I just feel it will make Java stronger to have everybody on the same page. We now have this with persistence, would be cool to get it with a component model.
Sep 21, 2007 @ 13:46:23
Many of these organizations were married to standards and wouldn’t go proprietary, even though Hibernate was open source. What ended up happening was that when we brought Hibernate to the EJB 3.0 and JPA specification, Hibernate was recognized immediately as a migration path to EE 5.
Bingo – Spring looks very powerful, but as Bill mentioned, standards to follow and (although scary) knowing when you pick a standard there are multiple implementations to choose are absolutely huge for commercial/business decisions on technology.
Jan 29, 2008 @ 00:28:00
Hi Bill,
Well am really getting pissed off with all this Spring cheap marketing and unwillingness to join the standardisation effort.
For the JEE6 yes we need a sophisticated IoC mechanism and really think Guice is a natural feat here as it’s already annotation based and interfaces based.
Another must would be Aspects, we’ve got a lil dose of them with the interceptor mechanism in JEE5, We got addicted and we need more and more 🙂
Oh the component model, I think we have that with Seam/web beans nope?
Cheers
Daoud AbdelMonem Faleh
Jan 29, 2008 @ 13:34:16
Daoud, you sould see how they act on the EE 6 specification. IMO, they are only interested in EE’s demise based on their behavior there. Which is stupid as without EE there would be no Spring.
Spring Source: The drug dealer approach to OSS « Angry Bill
Sep 23, 2008 @ 22:09:09