Spring Framework 4.0 Announced
After nearly four years the popular Spring Framework is getting an upgrade from version 3 to version 4.
Spring Framework cofounder and project lead Juergen Hoeller announced on his blog that the first milestone has been cut, although no early-access download link was provided.
The theme of version 4.0 seems to be Java SE 8 (based on OpenJDK 8 build 88+) and Java EE 7 support, plus some new usability features.
Juergen states that Java SE 8 support is a work in progress (ostensibly because Java SE 8 is a work in progress). He says to expect a release candidate around September 2013, to be timed with JDK 8 Developer Preview date also scheduled for September. (See the schedule at the Open JDK JDK 8 landing page). It will be presented at SpringOne (September 9-12).
Some of the Java SE 8 features to be supported include:
- JSR-335 Lambda expressions.
- JSR-310 Date-Time value types for Spring data binding and formatting.
- Support for the new 1.8 byte code format (required to support Lambda expressions).
Some of the JEE 7 features include support for:
- JSR-343 JMS 2.0.
- JSR-338 JPA 2.1.
- JSR-349 Bean Validation 1.1.
- JSR-236 Java EE 7 Enterprise Concurrency support.
- JSR-356 Spring's WebSocket endpoint mode.
SpringSource also intends to add the hypermedia REST constraint HATEOAS to the framework in parallel. HATEOAS is considered by RESTafarian orthodoxy to be a defining principal of REST. By adding HATEOAS support SpringSource is expected to mainstream that RESTful feature.
Spring 3.0 was first released in December 2009. Spring 3.1 followed in December 2011. Spring 3.2.2 was released in March 2013. Along with this announcement is the release of Spring Framework 3.2.3, containing bug fixes and OpenJDK 8 runtime support.
Re: Slow down
It is crystal clear that if the main theme of Spring 4 is Java 8 then the new version will not be final before Java 8 is actually released.
Nothing on CDI nor JAX-RS ?
BTW, I think Spring 4 will implement JTA 1.2 (meaning you will be able to use the @Transactional from JTA, and not the one from Spring, without EJBs)
Re: Slow down
Note that we have a quite ambitious release plan here, so we decided to *not* tie ourselves to the OpenJDK 8 GA timeline after they changed their GA target from September 2013 to March 2014. As a consequence, we intend to go 4.0 GA in Q4 this year, against OpenJDK 8's Developer Preview.
Since OpenJDK 8 is almost feature complete now, we do not expect any compatibility problems beyond September. It's just that we can only declare JDK 8 production support once JDK 8 goes GA next year, likely shipping a corresponding Spring Framework 4.0.x release right after OpenJDK 8 GA.
So Spring Framework 4.0's general feature set will be perfectly usable in production on JDK 6/7 in Q4 2013. In addition, early adopters of JDK 8 may start using our 4.0 releases for their development projects as well. We believe that this is the best possible compromise for our target audience.
Re: Nothing on CDI nor JAX-RS ?
Our ongoing vehicle for REST support is the Spring MVC programming model which serves as a flexible dispatching platform for any kind of web request processing, and we keep evolving it that way. JAX-RS, nice as it is, has a somewhat different model, in particular towards endpoint structure and lifecycle. All of the existing JAX-RS providers support integration with Spring, so they remain a fine alternative to Spring MVC. Nothing wrong with those choices from my perspective; it's just like with Wicket versus JSF.
As for CDI and general Java EE compliance, Spring keeps up its position as an application framework that integrates with many kinds of runtimes. We have no ambitions to become a Java EE container; we 'just' keep supporting Java EE servers as a first-class deployment target for Spring applications. At the same time, we support very different architectures as well where the EE platform plays no role at all - and where Spring's configuration model, its flexible transaction model etc really show their particular strenghts.
What specific Lamba features will show up where in Spring
Re: What specific Lamba features will show up where in Spring
We consider overloading a few template methods to accept variations of specific functional interfaces, as an alternative to Spring-provided base classes that pre-implement some callback processing. Other than that, it's mostly about testing actual compliance - and about accepting 1.8 bytecode at runtime, since lambdas only work with -source 1.8 -target 1.8.