VMWare to Acquire SpringSource for $362 Million

Actually Spring doesn't need to run on a certain middleware, and even if people decide to do so, the plattform would be OSGi (SpringDM), not just the OSGified Version of Tomcat, and Tomcat is based on JEE standards.

Why would a Standard from the JCP be better than any other Specification/Framework?

EJB 1.x to 2.x was an abomination, JSP is dying, EJB3.x still lacks important DI features, JPA 1.0 is missing many nessecary features.

Even if EJB 3.x is "good enough", Spring offers way more for instance when it comes to DI (not to mention all the other Spring modules), and does so since years.

For me, there is no point in trying to pretend that the JCP Standards are better than successfull OSS Project, but not nessecarly the other way around.

Use what you need because of the requirements, not because somebody says it's a standard.

I'm genuinely happy to see Rod and SpringSource cash in big-time.

I think history will remember Java EE 6 as being the first fully usable JEE stack.  Before JEE6, I think libraries like Spring and Hibernate were necessary.  I'm going to give the new WebBeans/JCDI, EJB 3.1, JSF 2.0, JPA 2.0 and JAX-RS a try on an upcoming personal project.

Personally, I couldn't care less what light Spring is put in.  Spring is good as it is.  But so is EJB3.x.

I just often come to EJB3.x's defense because these boards get lots of Spring fans dumping on EJB3.x.

There is often a knee-jerk anti-standards stance, and anything that is non-standard, or open source, is awesome.

I only want to make sure people understand that EJB3.x is good, and easy, and powerful, and that Spring is not the be all to end all.

And in my experience, I have found EJB3.x easier and more pleasant, as well as more powerful and comprehensive, than Spring.   I just like it (EJB3.x).  That's all.  It's not anti Spring.

One more point about standards - besides making code more portable, by using standards you also insure that your code is more maintainable in the future because standards ensure that there will be an ecosystem of knowledgable developers who can be productive.

"But with Spring beans, you're stuck with Spring. You are married to the Spring container. Sure, the Spring container works with a bunch of app servers. But you still have to use it."

I have no idea how you can make this assertion. I use beans of all sorts, many configured in Spring, that work in Tomcat just fine - I've never used any of the Spring server products. If by 'container' you mean the Spring IOC/AOP framework, then I would not say that is a 'container', but even so, any of my beans will work outside of that framework. The framework just provides a nice way to configure and reuse the beans.

'Spring' is a lot of different APIs, most of which they have done a pretty good job of making standalone and not tightly coupled.

I'll be interested to see what VMWare has in store for Spring. I am hoping that we will see some really nice virtual machine Java technology stacks that are easily and readily deployed. I am not particularly interested in 'clouds' or grids, etc. at this point, but I would like to see some nice virtual appliances come out of this that are geared towards Java dev and deployment.

Being a "fan" of EJB3.x or Spring, or anything else, is stupid.  I'm not a fan of either.  I use what makes sense for the current use case, or what my current employer requires.

I might come off as a "fan" of EJB3.x.  

 But my posts are reactions to people posting stuff like:

"Spring is a de facto standard"

"EJB3 lacks full support of DI/AOP"

"App servers suck"

"JCP standards suck"

"It has 'EJB' in it's name, and EJB2 sucked, therefore it must suck"

Or something along those lines.

Plus, I'll say it again.  EJB3.x is quite nice.  I like it.  So shoot me. ;-)

But saying that doesn't mean I don't think Spring is good.  I do think it's good.  Thinking one is good is not mutually exclusive to saying the other is good.

JeffS,

That's fine. I have read that EJB3 is much better/etc. than previous EJB APIs - I am not criticizing it, I don't know much about it at all having never used it, so I can't compare it to Spring.

I am just saying that I have a little experience with Spring and overall I find it very non-intrusive, you aren't 'married' to it if you later decide to go another route and you don't have to use any particular server product to get its benefits - for example, I also use it with Swing desktop apps. Indeed, one of the things I like about the IOC/AOP configuration part of the Spring framework is that it really helps decouple different components/modules and strategies from various implementations. If I want to change my persistence from Hibernate to iBatis, Spring really helps there. If I want to use a different security strategy/implementation, Spring really helps there too. Overall, if I use a basic setter/getter configurable bean and interfaces, I can use Spring IOC to plugin whatever implementation of some other component without changing a single line of code.

The IOC/AOP portion of Spring is a core part of the Spring framework, but there are a lot of other APIs in Spring that provide some very nice functionality and help decouple various layers and components, and if by 'container' you meant their server app containers such as dm Server, then I have never used those (yet) - indeed, I know almost nothing about them. So I am certainly not married to them or Spring - I can use my beans elsewhere as I wish, and I do.

"Thanks to Spring there is EJB3.x but still not there. EJB3 need the JCP and its slow as hell while Spring already fixed all the isues. I prefer OSS projects because are more dynamic than JCP ones and their implementation."

Good point.  Spring really lit a fire under their backsides, didn't they.

 But I will say this - EJB3.x was first to the table with annotations (as opposed to XML config), and convention over configuration.  Then Spring offered the same, but only after EJB3.x did.  That's cool though, because competition breads innovation.  Let 'em leapfrog each other, to our benefit! :-)

Btw - annotations and convention over configuration are two things I really really like about EJB3.x.  I'll take that over XML hell any day.  

Yes, I do know that Spring has annotation/convention support as well, but I can't comment on their implementation of them as I haven't tried them yet.

I do know that all that XML configuration in Spring left a really bad taste in my mouth.  It was a big improvement over all that bloated, complex EJB2 crap.  But it was still a pain.  Not to mention that a lot of app behavior, indeed bean wiring, is controlled by the XML, which effectively takes the compiler out of the equation, and makes debugging more difficult.

But it's all good. 

Spring led the POJO / DI / AOP decoupled way.  EJB learned and did the same.

Then EJB accomplished POJO / DI / Interceptors / Behavior via annotations (or XML, if one so chooses), being much simpler and elegent.  Then Spring adapted the same.

Then Spring accomplished great modularity and OSGI support.  EJB 3.1 is now offering the same.

 That's great!  Let 'em duke it out, leap frog each other, and we get to enjoy the benefits!

"So, again, why should people confortable with Spring move to EJB? Just cause it's a "standard"?"

They shouldn't.  

If you have something that works and you're comfortable with, there is no reason change.  If it ain't broke, don't fix it.

But it works the other way, too.   If people are comfortable with EJB3.x and it works for them, why should they move to Spring?  Just cuase it's not standard?

Answer:  They shouldn't.

 But greenfield applications need to weigh the plusses and minuses to both Spring and EJB.

Personally I would of plugged to stay autonomous till 2010 and then looked for an IPO based on improving market conditions. Perhaps it was the VC's that really were concerned and wanted out.