I have not used JavaEE6.
However, I’ve been abused enough by all previous versions of JavaEE and EJB that I won’t trust it until it establishes itself as the de facto standard, not just the legal standard. Right now, spring is still the de facto standard.
You fool me once, be ashamed. You make fun of me twice, be ashamed. You tease me three times, EJB.
Some will claim that Spring is proprietary. I would argue that the vendor’s implementations of the JavaEE specification have been just as proprietary, if not more so.
I recently went through a major conversion by moving a group of Java Applications from JBoss to Weblogic. All Spring / Hibernate apps were ported with zero changes, because they had all the libraries they needed.All apps that used JPA, EJB and JSF were a mess to port. The subtle differences in interpretations of JPA, EJB, and JSF between app servers have caused all kinds of nasty bugs that took a long time to fix. Even something as simple as JNDI naming was completely different between AppServers.
Spring is an implementation. JavaEE is a specification. This is a huge difference. I would prefer to use an IF specification the specification was 100% airtight and left absolutely no room for how suppliers implement that specification. But the JavaEE specification was never like this. Maybe JavaEE6 is more hermetic? I do not know. The more you can package in WAR, and the less you depend on the AppServer libraries, the more portable your application will be, and this, after all, is why I use Java and not Dot-NET.
Even if the spec were watertight, it would be nice to be able to update the appserver without having to update all my tech stacks in all my apps along with it. If I want to upgrade from JBoss 4.2 to JBoss 7.0, I have to consider the impact of the new version of JSF on all my applications. I don’t have to consider the impact on my Spring-MVC (or Struts) applications.