At Spring One 2021, VMware revealed how Spring 6, planned for an October 2022 release, prepares the framework for another decade: it will require Java 17 and Jakarta EE 9, provides first-class support for Java modules and native compilation, bakes observability into Spring, and drops outdated features and third-party integrations. Spring Boot 3 will use Spring 6 but has no release date yet.
Demonstrating the magnitude of this overhaul, the Spring Framework will not have a new major release this year - for the first time since 2010. However, an upcoming minor release will support Java 17, while the Spring Boot 2.x.y release train will still get major releases in November 2021 and May 2022.
Recent developer surveys showed early adoption of newer cloud-native Java frameworks, such as Quarkus and Micronaut. These frameworks produce native applications with low memory usage and fast start-up times. Spring 6 may be seen as VMware's response to these competing frameworks.
Spring 6 will have the usual overlapping maintenance release branches. But "Spring Framework 6 users are strongly encouraged to join our stream of feature releases, not expecting to stay on 6.0.x for long, but rather making the 6.1, 6.2, etc. upgrades a part of their regular usage model."
The release cadence may also change from an annual to a semi-annual cycle, as Spring Boot already does.
Requiring Java 17 is less aggressive than it sounds today; by the time Spring 6 ships, Java 19 will have been released. Jakarta EE 9 as the baseline breaks backward compatibility with the new jakarta package namespace, but allows Spring to keep up; some Spring dependencies already support Jakarta EE 9 (such as Tomcat 10 or Jetty 11), while others won't until next year (like Hibernate ORM 6).
Spring 6 is expected to use the Java Platform Module System (JPMS) and allow developers to write Spring applications with the JPMS.
Spring Native provides native compilation of Spring applications with GraalVM today. It will improve further with the release of version 0.11, scheduled for November 19, 2021, which will rely on GraalVM 21.3 and Spring Boot 2.6. But Spring Boot 3 will seamlessly integrate native compilation with a starter configuration and build packs, replacing Spring Native in Spring 6.
Spring Boot 3 will probably not offer native compilation of all Spring Initializr libraries right out of the gate. And as is the case with other frameworks, there's currently no easy way to know whether any given Java library works in native mode.
Spring Observability is a new project in Spring 6 and builds on lessons learned from Spring Cloud Sleuth. It records metrics with Micrometer and offers tracing through providers such as OpenZipkin or OpenTelemetry. Unlike agent-based observability, Spring Observability will work in natively compiled Spring applications. And as part of the core Spring Framework, it will also more effectively provide better information.
VMware provided some examples of outdated features it plans to drop, namely autowiring setters by name/type, some FactoryBean arrangements, and "certain web-related options." EJB and JAX-WS are third-party integrations that may be removed from Spring 6.
The first Spring 6 milestone is planned for late 2021 with a release candidate scheduled for July 2022. VMware invites community feedback on its plans for Spring and Spring Boot.
InfoQ caught up with Kristen Strem, senior communications manager at VMware, who served as liaison to the Spring team with questions about Spring Framework 6 and Spring Boot 3.
InfoQ: Version 6 prepares the Spring Framework for another decade. Why was this necessary and why now?
Kristen Strem: We see a major turning point for the Java ecosystem with the industry finally embracing next-generation Java and moving JDK 8 to legacy status for legacy systems. We expect JDK 17 to play a key role in this shift, delivering an attractive new Long-Term Support generation with many accumulated Java language, API and VM enhancements - more so than JDK 11 LTS which mostly just got adopted as a plain JDK 8 replacement for support policy reasons. In addition, there is not just JDK 17 as a new LTS generation, we also expect further key benefits in upcoming JDK feature releases - e.g., Project Loom - which we intend to optionally support while retaining a JDK 17 baseline. Eventually, we'll still support JDK releases up until JDK 29 LTS in our 6.x line.
InfoQ: You compared the Spring Framework 6.x feature releases to the OpenJDK release model. Does this mean once a new release 6.x is out, that you will stop producing releases for the previous release branch?
Strem: In terms of open source maintenance releases, we'll keep up the same model as in recent years, with overlapping maintenance branches as usual. The OpenJDK release model provides inspiration in how major features such as Project Loom support can be rolled into 6.x feature releases rather than a new major generation of the framework. Also, we might provide more frequent 6.x feature releases at the core framework level, joining not only OpenJDK, but also Spring Boot in releasing feature iterations twice a year. Last but not least, Spring Framework 6 users are strongly encouraged to join our stream of feature releases, not expecting to stay on 6.0.x for long but rather making the 6.1, 6.2, etc. upgrades a part of their regular usage model.
InfoQ: You demonstrated how Spring 6 developers could quickly reload and debug their running application in Kubernetes. Does this require the Tanzu Application Platform? If so, do you plan to make this available to every Kubernetes installation?
Strem: You don't need any Tanzu specific technologies in order to support reload and debugging of applications in Kubernetes. Spring Boot has shipped with a devtools module since v1.3 which works very well with Kubernetes. There's often a few decisions that you'll need to make around what tools to use and how to configure them. There's a good overview of this in the "Inner Loop Development with Spring Boot on Kubernetes" talk presented by Dave Syer at this year's Spring One .
Of course, part of the value of the Tanzu Application Platform is that we can provide sensible integrations with the tools that we know work well with Spring, and we can automate a lot of things so that developers don't need to worry about them. That's something that many of our customers want and you can see that automation in action during this year's SpringOne keynote.
InfoQ: Many frameworks, including Spring, use GraalVM for native compilation. How do you see Spring cooperating with these frameworks to improve native compilation for the entire Java community? For example, you mentioned a repository with GraalVM compatibility for Java libraries and benchmarks by the GraalVM team at Spring One.
Strem: From day one, the focus of the Spring team has been on helping to mature the native Java ecosystem via a deep collaboration with the GraalVM team. The native build tools, which allow to build and test native executables via Gradle and Maven plugins, are a great incarnation of that. It was initiated by Spring and GraalVM teams, with some contribution to the JUnit project. Recently the Micronaut team joined forces, and similar collaborations would be very valuable for the Java ecosystem.
Having a shared vision between Spring and GraalVM teams about how to make the native Java ecosystem more sustainable and maintainable also allows deep collaboration on the native configuration project, which should provide guidelines and tools to have shared native configuration across various frameworks. Notice this kind of effort is made possible by leveraging recent improvements in GraalVM native support: native testing, native configuration improvements, inlining at build time, etc.
In the end, it is perfectly fine and expected that each framework should provide its own "secret sauce." But the native Java ecosystem can't be sustainable without more shared support in Java tooling and libraries, and we will continue to put a lot of effort on this kind of collaboration with the wider ecosystem as part of our work on Spring Boot 3.x first-class native support.
InfoQ: In April, Juergen Hoeller wrote that they're considering "the introduction of module-info definitions across the codebase" for Spring Framework 6. Does this mean that Spring Framework 6 will bring out-of-the-box support for writing Java applications with the Java Platform Module System?
Strem: Spring Framework 6 is indeed expected to introduce module-info descriptors for all core framework modules, with minimal required dependencies on core Java modules, enabling the JDK's
jlinktool to build custom runtime images for Spring setups. There might be constraints with optional third-party libraries and certain configuration strategies, so it is still unclear how popular such explicit module usage will become among Spring users. Up until this point, we have not received many requests for it, despite a lot of general interest in recent Java versions.
Videos and slides of related Spring One sessions are available: Spring 6, Spring Native, and Spring Observability.
