VMware offers training and certification to turbo-charge your progress.Learn more
Note that there's a follow-up blog post about Spring 5 system requirements. You might want to start there if you're primarily interested in the Spring 5 planning process.
In our quest for Java EE integration, we're trying to actively embrace the latest generation of specifications such as JPA, Bean Validation and of course the Servlet and JMS APIs. As of Spring 4, we're supporting the Java EE 6 and 7 level of specifications side by side. We would like to raise it to the EE 7+ level (JPA 2.1, Bean Validation 1.1, and in particular Servlet 3.1 and JMS 2.0) soon but are facing a fundamental problem: the lack of EE 7 platform adoption.
The Java EE 7 platform has been released in May 2013 and is therefore two years old now. Surprisingly, it's hardly to be found in production yet. But then that's not so surprising really: While a few projects have been certified for EE 7 in the meantime, the lack of major vendors is apparent: There are no major EE 7 servers with production support yet, not for the web profile and not for the full platform either. As of June 2015, the common EE vendors still sell licenses for servers based on 2009-era Java EE 6 APIs. And it's not just the traditional suspects:
HOT NEWS (June 9): An EE 7 fixpack for WAS 8.5.5 will go GA on June 26. Kudos, IBM!
While several specifications from the EE 7 umbrella have seen individual adoption, e.g. JPA 2.1 through Hibernate 4.3 and Servlet 3.1 / JSR-356 WebSockets through Tomcat 8 and Jetty 9, it is fair to say that Java EE 7 failed to enter the market as a platform overall. After all, the point of a “platform” is widespread mainstream availability. Ironically, the later-released JDK 8 (March 2014) got embraced in production rather quickly, even in EE land! So the state of the art as of mid 2015 is a vendor-supported Java EE 6 server running on JDK 8 in production...
Our consequence: Given the adoption levels of Spring 4 and Java 8, we'll raise the minimum to JDK 8+ in our Spring Framework 5 generation. However, due to the lack of Java EE 7 platform adoption, we'll have to retain compatibility with the current generation of application servers: allowing for upcoming Spring 5 applications to be deployed to the JDK 8 based EE 6 servers commonly found in production - just like we do with Spring 4 already, but at least with the extra benefit of going JDK 8+ for our framework codebase and all of its core interfaces.
P.S. (June 6):
FWIW, I really appreciate GlassFish and WildFly as open source engineering efforts. Spring has dedicated support for both, and the Undertow HTTP server (under the WildFly umbrella) is a great fit for embedded deployments with Spring Boot. This doesn't change the fact that the project owners (Oracle and Red Hat, respectively) refrain from supporting them, choosing to invest into WebLogic 12 and JBoss EAP 6 for production purposes instead. External support from the likes of Payara (for GlassFish) can only mitigate this to some degree, with large parts of the Java EE market bound to the vendor production offerings - all EE 6 based - in 2015.
For an example for fine production support from the open source project itself, look no further than Tomcat. The Tomcat project has an admirable track record of fixing bugs and in particular security vulnerabilities very quickly, even across the past three major generations of the server. So I'm not arguing for commercial support per se, I'm arguing for proper maintenance releases like Tomcat does (and dare I say: like Spring does), whether from the open source project itself or from a commercial support subscription. WildFly for example doesn't have either of those; GlassFish comes with no support from Oracle but at least has a support option via Payara.