Shared publicly  - 
Let's see if G+ works better for this than twitter does. I'm not going to write a blog-post about it. But I feel the need to say a little bit more than 140 char about it ;)

I finally stumbled upon +Arun Gupta ( and +James Bayer ( s posts about #JavaEE6 vs #Spring . And even +Antonio Goncalves jumped in with some comments about it (

I'm an Java EE advocate since years now. And even I had to work with #Spring and a lot of it's components. There have been times when it was a true lightweight pleasure to use what former springsource team had to offer. Especially if you were into MDD or stuff like that quite early. The whole problem I have seen with customers using one or the other is that they mad a decision about this. And started defending it over and over again. For years. Until today. No matter which arguments were standing in the room. With spring starting to offer non-standards compliant solutions for problems the standards had back in the days some companies missed to jump back on the standards train at all. And they are paying for that. The one or the other way. Maybe by not being able to attract young developers. Maybe by having to wait for a solution. Maybe by no longer being able to use or integrate with upcoming standards. Maybe by something else. Maybe I missed something here.
It's obvious less risky to have a first class ticket on a standards-driven train. But it was expensive until #JavaEE6 came up. Why? Because you had to take the long road on some things. You had to implement a lot. You had to cope with shortcomings and with some older standards you also had to commit yourself to a vendor (CMP). So to me it seems as if sticking to the JavaEE standard just started to pay back to those sitting there since the beginning. And to me it feels as if this train only recently started to gain speed again. Without having looked into the separate features and components I have the feeling that from a technology point of view the break even for using the JavaEE standard in favor of spring has come.

As a consultant I have to look at the customer first. So, depending on the shop the customer is in, I have to choose which way to go. If someone is asking me what to do I would propose a broadly adapted standard. As of today. For enterprise grade #Java this clearly is Java EE.

Some (personal) last sentences to +Arun Gupta and +James Bayer :
I thankfully know both of you. You have been on the same company for quite some time working in the same field. I don't know if I like to see what's happening via your blog-posts at the moment. You should sit together and work out a common view on both platforms and start offering a real decision matrix. Step back from positions and start offering solutions. Anybody skilled enough to work with any of the two platforms knows about this "ancient fight" and has his positions here. So you both are targeting the young ones, the greenhorn developers with this discussion. And you should, no you have to, make this a valuable discussion.
But those are only my 2 cent.
Eberhard Wolff's profile photoWerner Keil's profile photoJames Bayer's profile photoDerlon Aliendres's profile photo
As Java EE EG Member, JCP EC Member and proposed Co-Spec Lead of JSR 357 (Social Media) I also added my 2 Danish "Corona" to this;-)
After many successful years in the trenches with Spring Framework, I can honestly say that my recent forays with JEE6 have been a breath of fresh air, exhilarating even. For the Spring die-hards who are digging their heals in, I wish you all the best. For the newbies looking for some direction, I encourage you to start at JEE6. Spring is still on my CV but it's definitely not what I am looking for in a tech stack anymore.
We had very similar experience in some of the largest scale Enterprise projects around the world. E.g. Spring's JMS templating our local Offshore partners insisted on using, caused trouble with transactional context (especially cause AOP was pushed in everywhere, you also see it in the dependency list of Arun's blog), while e.g. a simple MessageDrivenBean approach in a much larger project for a leading telco worked smoothly, even with 2 different versions of WebLogic and J2EE as it was called back then;-) Here in another Scandinavian project for one of the largest vendors in its industry, we build Java EE 5 and above, and rarely any project here seems to use Spring. The only place with vmware heavily used is OS virtualization...
Markus, I appreciate your point of view. You are keeping it real, which I tried to do in my response as well. I just saw Arun not too long ago and we talked for quite awhile and we get along great. However, this idea that the Java EE advocates are publicly trying to spread FUD in a seemingly coordinated way with weekly blogs and not present any balance is just silly in my view. When I worked at BEA and Oracle the Spring + maven world seemed more complex to me because I was unfamiliar with it and typically started development as IDE-assisted. I think in practice that It's very common in the real world for people to mix Java EE and Spring, so the idea of forcing it to be a mutually exclusive choice isn't representative of how many people view it.
Yeah, I quite agree JamBay.
IMHO, I we all otta (keep on) use(ing) Spring (or even Seam FrameWork) the way as close compliante to JavaEE6/JSRs as possible.
Because, as we know that there are things, like cloud, that JavaEE 6 sucks (and by other hand, things like WebServices - Spring sucks; JAX-WS is pretty simpler and efficient).
I think there is a thinking line quite mislead (mostly of pure JavaEE 6 advocaters) that we should define, for ex., the EntityManager in the container (EJB+Web) and the DataSource in the App. When should better be the opposity. :O Thus, whem JavaEE advocaters say their way yields + portability, we get the opposity, because, for ex/, the JPA implementation of WebSphere (EclipseLink I guess) is quite different of JBoss (Hibernate). What do we get?= 0.0% of portability in this matter, get it?!!
Add a comment...