The title and some of the subheadings in the German article "JavaEE failed to enter the market: why Spring 4 is planning without JavaEE7" don’t necessarily recap Jürgen’s blog post.
"Why Spring 5 is planning without JavaEE 7" — the opposite of that is true. The framework already supports a lot of specifications of the JavaEE 7 release: Servlet 3.1, JTA 1.2 (@Transactional), JPA 2.1, WebSocket 1.0 etc. are already supported by Spring 4. The JCache support in Spring is so old (introduced in 4.0), many Java developers don’t even realize that the spec hasn’t been included in any official JavaEE release yet.
It’s a matter of fact that for a lot of projects that run on application servers like IBM WebSphere and Oracle Weblogic using Spring as a platform is the only way to use these new APIs at all. Speaking of a "Spring VS. JavaEE" is indeed wrong. But what is it, that Jürgen is duiscussing in his blog post?
The post is taking an inventory of the JavaEE world in relation to the project planning for Spring 5. We usually use major version bumps in the framework to raise certain base lines regarding the referenced platforms. For the JDK this will be version 8, mostly because it has gained a lot of traction and is used quite widely already — one year after its release.
Unfortuately the picture is quite different for JavaEE: as it can be seen here, the number of JavaEE 7 certified application servers is pretty low. For the planning of Spring 5, it’s especially remarkable that for the server implementations that cover a broad spectrum of the market (Oracle Weblogic, IBM WebSphere, JBoss Wildfly, Tomitribe TomEE) there either is no JavaEE 7 implementation available or the existing implementations are not commercially supported and only see sporadic updates (e.g. Glassfish — 1 feature release as of 4.0 (2 years), no bug fix releases).
This situation makes it pretty much impossible for customers of those vendors to upgrade to a version that supports JavaEE 7. Switching to one of the newer vendors (Payara etc.) is often not considered due to the lack of trust (justified or not), migration efforts etc. The bottom line is: a majority of the application server users can’t and won’t upgrade to JavaEE 7 soon — 2 years after the spec was released.
Thus, if Spring 5 required JavaEE 7, we’d cut off exactly this majority of the market as it would not be able to upgrade to exactly that version of Spring. That’s why Spring 5 is going to stick to JavaEE 6 as minimum baseline. No more, no less is in Jürgen’s post. Turning that into a "Spring VS JavaEE" is quite adventurous, I think.
To sum things up: current Spring 4 already supports a lot of JavaEE 7 APIs, Spring 5 will do as well. Depending on the progress of JavaEE 8 until its release date, Spring 5 will definitely support the upcoming spec versions, too, just as has always done.
This may be true, and over at OmniFaces we had a fierce debate a while back about exactly this point; should be have Java EE 7 as a minimum baseline for OmniFaces 2.0 or not (after a community poll we decided we more or less should, but the dice could have rolled the other way, especially since back then there were even less compliant servers).
The problem is however that the tone of the original post made it sound as if Java EE 7 is a special kind of failure. That it's exactly Java EE 7 that failed, while for instance Java EE 6 was adopted fairly rapidly.
This is not the case.
I did some research into this a while ago (see http://arjan-tijms.omnifaces.org/2014/10/java-ee-process-cycles-and-server.html), and until now the pace is approximately the same as it was with Java EE 6. For better or worse, 2.5 years was the time it took for "most" servers being Java EE 6 certified last time around. At nearly exactly 2 years, the original article was perhaps a bit too fast to declare failure for Java EE 7.