VMware's SpringSource team have recently announced plans for Spring Framework 4.0, the next update to the framework, with new features including support for Java SE 8, Groovy 2, parts of Java EE 7, and WebSockets. The plans were discussed in more detail at the end of webinar covering the 3.2 release.
The full list of planned features and updates is:
- First-class support for Java SE 8 based Spring applications:
- language features such as lambda expressions; APIs such as JSR-310 Date and Time
- Configuring and implementing Spring-style applications using Groovy 2:
- Groovy-based bean definitions; Groovy as the language of choice for an entire app
- Support for key Java EE 7 technologies:
- including JMS 2.0, JPA 2.1, Bean Validation 1.1, Servlet 3.1, and JCache
- Enabling WebSocket-style application architectures:
- support for JSR-356 compliant runtimes and related technologies
- Fine-grained eventing and messaging within the application:
- building on our existing application event and message listener mechanisms
- Pruning and dependency upgrades:
- removing deprecated features; raising minimum dependencies to Java 6+ etc
InfoQ spoke to Spring framework co-founder Juergen Hoeller to find out more about the plans.
InfoQ: Can you give us some idea as to where you think Lambda will be useful within Spring; I guess the callback programming model for JMS would be one such?
Effectively, all Spring template classes (e.g. JmsTemplate, JdbcTemplate, TransactionTemplate) have been using a callback-oriented programming style for years - which turns out to be a great match for lambda expressions, since the established callback interfaces there are natural functional interfaces for use with Java 8 lambda expressions. We also expect strong lambda adoption in asynchronous programming models, such as fork-join tasks and async web request processing, which we've done quite a bit of foundational work on in the Spring 3.x generation. Our goal is to provide a very smooth and natural experience when using Java 8 language features in combination with Spring 4 APIs.
InfoQ: How much impact will JMS 2.0 have on Spring?
We are really happy to see a revision of the JMS specification after more than ten years since JMS 1.1. However, it turns out that the actual content of the spec isn't radical at all but rather just catching up with the times. We are going to support the new send options (delivery delay, asynchronous send) in JmsTemplate, and we'll also allow for using the new JMSContext client API as an alternative to Spring's JmsTemplate. So JMS 2.0 itself doesn't have much architectural impact; it is primarily a trigger for us to revisit the role of JMS in a variety of Spring-based application architectures. As a consequence, any such further JMS support in Spring is expected to remain JMS 1.1 compatible.
InfoQ: Loosely related to JMS are the kinds of WebSocket applications that will be supported through JSR-356. What are you plans here?
We have been researching WebSocket adoption in the industry for a while now and are strongly interested in what JSR-356 will come up with - but also in related technologies, both for deployment on mainstream Servlet containers and for embedded HTTP endpoints with minimal server arrangements. Our goal is to provide a straightforward extension of the Spring programming model with respect to exposing WebSocket-style endpoints, ideally in sync with our plan for generally refined support for messaging endpoints in Spring-based applications. We remain pragmatic there; we'd really like to provide something WebSocket-oriented that Spring users find useful right now with 2013's infrastructure.
InfoQ: The plan mentions the new Java Date and Time API specifically. Can you give us some examples of where that will be supported?
Spring Framework 3.0 introduced extensive support for date binding and rendering using the JodaTime library. JSR-310 is essentially a standardized version of JodaTime, even if there are some differences in its design. We will support JSR-310's value types as a first-class target for Spring's @DateTimeFormat and related conversion functionality, and we intend to recommend its use in the very heart of application domain models.
InfoQ: I notice you are making a large investment in Groovy. Do you see Groovy 2.0 as an alternative to Java for large-scale application development - is the performance good enough, for instance?
That's a key question, and we're basically on a mission to find out about it. We see a lot of potential in stronger Groovy support in the core framework: for Groovy-based bean definitions (a.k.a. the Grails BeanBuilder), for next-generation scripting support, and also for using Groovy 2 with its static compilation mode as the primary implementation language of a Spring-based application. Groovy's performance is particularly good with the static compilation mode already and will only be getting better.
InfoQ: Are there specific features of Groovy that you feel make it better suited to Spring development than Java?
Well, Groovy is quite close to the Java language in many ways and has very natural interoperability with Java. Particularly important with respect to Spring are Groovy's strong support for Java annotations and its support for closures as method arguments to Java APIs. For a traditional Java audience, Groovy is a very natural step to take. Beyond that factor, Groovy obviously has so many nice little language features which you may selectively, or even wholeheartedly, adopt while not giving up on traditional Java semantics. For a taste, check the pragmatic focus of the features in the recent Groovy 2.1 release.
InfoQ: Are you favouring Groovy to the detriment of Java?
No, definitely not. We are embracing Java the language wholeheartedly, in particular Java 8's language style - but at the same time, we are very open to alternative languages as well. We're not just investing into Groovy, but also into Scala and others. However, for a core Spring audience, Groovy has a sweet spot, and we'd definitely like to explore that sweet spot next to our Java 8 language story. Personally, I think it's great for us to work on those side by side; there'll be quite a bit of cross-pollination.
InfoQ: What are your plans for JCache Support - I know you have early support for it 3.2 but how do you expect that change when JCache ships with Java EE 7?
Once JCache is final, we'll make sure to support all the options that JCache provides for CacheManager setup, including transactional and distributed variants. We also intend to support JCache's set of caching annotations as an alternative to Spring's own caching annotations, out of the box in Spring Framework proper. At the same time, we expect a reinvestment into our native EHCache support, making sure that it is at the same level as our JCache support and also catching up with new features in the recent EHCache 2.5+ releases. Spring Framework 4 is generally an opportunity for us to catch up with the latest features in common third-party libraries and to require more recent versions at runtime there.
InfoQ: Since you are bumping up the minimum dependency to Java EE 6 does that mean enterprises stuck on older versions of Application servers that only support Java EE 5 - WebLogic 10, WebSphere 7 - won't be able to use the new features?
A key part of the Spring Framework 4.0 plan is to tailor the framework more specifically to recent generations of Java SE and EE, so our baseline will be Java SE 6+ and Java EE 6+. However, we are making some compromises for Java EE 5 servers with EE 6 feature packs, e.g. for WebSphere 7 with the IBM JPA 2.0 feature pack or for WebLogic 10.3.4 with JPA 2.0 enabled, allowing Spring Framework 4.0 to run on those just fine. Technically, this means that we'll keep up Servlet 2.5 compatibility at runtime, even if Spring's web support is strongly oriented towards Servlet 3.0 these days. In any case, Spring remains on its mission to bring fresh programming model features to existing runtime platforms; that will still be the case with 4.0.
InfoQ: Last year seemed, from the outside at least, to be an eventful one for SpringSource with Rod's departure and VMWare's decision to spin the division out into a separate company. There's been some suggestion in the press and elsewhere that the Spring framework is kind of "done." How do you answer that charge?
The Spring open source team remains stable, with the very same people in key positions. Myself, I'm actually celebrating ten years of serving as the project lead for the Spring Framework open source project. Spring Framework 4.0 celebrates those ten years of Spring through a new generation of the framework, establishing a very up-to-date foundation for the years to come. We are by no means done, even if the changes in the core programming model aren't as disruptive anymore, not unlike what can be seen with Java EE 7 versus 6. There is also going to be a whole series of other project releases on top of Spring Framework 4.0, following soon after 4.0 GA.
The first milestone release for Spring Framework 4.0 is expected at the end of April. The GA release is planned for the end of the year.