You are here
Home > java >

New Features In Spring Framework 6

New Features In Spring Framework 6Spring Framework 6, released on November 2022, is the major version change and containing many upgraded features and changes into the Spring development environment. On the other hand, Spring Boot 3 also released on November 2022, is based on Spring Framework 6, also changes a lot of things. We need to know about the changes in new versions in order to make smooth development of an application in the future. In this article, we will discuss about ‘New Features in Spring Framework 6’.

Spring Boot 3.0 is also the first Spring Boot GA release to support Spring Framework 6.0. As a developer, we need to be aware of these updates in order to work smoothly with Spring Framework. Undoubtedly, one of the biggest turn in the Spring Framework 6 release was the dropping of support for older versions of Java. Let’s discuss our article ‘New Features in Spring Framework 6’.

What are the changes & the new Features in Spring Framework 6 ?

Below are the main features or changes introduced in spring framework 6:

Upgraded baseline Java version to Java 17

In order to empower the framework as well as applications, the minimum required JDK version to work with Spring Framework 6 is JDK 17, which is the  latest LTS (Long-term Supported) version. Java 17 includes various new features in terms of Language (text blocks, switch expressions), Core libraries (collection factory method, etc.), Type System (records, sealed classes), Module System (module introspection, module path scanning) etc. Hence, Spring Framework 6 takes maximum benefits from the APIs of Java 17. Spring

Going forward, Spring will recommend to use the latest available JDK/JVM versions. For example, if you are planning to upgrade your Spring versions such as 6.1, 6.2, 6.3, etc., consider upgrading the latest available JDK version as well in parallel.

Spring framework 6.1 GA is planned to release with the support of two major LTS versions of JDK, JDK 17 and JDK 21.

Changed the Namespace from Java EE with Jakarta EE

The Spring Framework 6 is migrated towards Jakarta EE from Java EE. Hence, It will use the ‘jakarta’ packages namespace in place of ‘javax’ namespace. For example, imports from ‘javax.servlet’ are upgraded to ‘jakarta.servlet’. Although Jakarta 9 is the baseline for Spring Framework 6, but Spring recommends to use the latest available version (Jakarta 10 as of now). For example, Tomcat 10 is based in Jakarta EE 9, whereas Tomcat10.1 is based in Jakarta EE 10. Spring framework recommends to use the latest compatible version of Jakarta EE.

AOT (Ahead-Of-Time): Build-time pre-processing of bean definitions

This is the new concept introduced in this version as a promising alternative for fast Spring application bootstrap. Typically in the development process, we compile the classes and package them before deployment. AOT comes between compilation & packaging. The Java compiler, then set of AOT steps, then packaging the application into the deployment unit. The AOT concept is handy if you are willing to make further steps at build time and reduce the startup time. It is known for extra build setup and less flexibility at runtime.

It analyses Spring application, reads all runtime hints and feeds them into the GraalVM native images and let’s GraalVM do its job. For the initial production support, AOT arrangement in Spring Boot 6.0 ships with pre-processing of Spring based application context at build time for a more efficient startup at runtime and for the input to the GraalVM native image.

GraalVM Native Excecutables

GraalVM is a high-performance JDK intended to speed up the execution of applications written in Java and other JVM languages.

GraalVM Native Images are standalone executable that can be generated by processing compiled Java applications ahead-of-time. Native Images generally have a smaller memory footprint and start faster than their JVM counterparts. GraalVM Native Images provide a new way to deploy and run Java applications. Compared to the Java Virtual Machine. Native images can run with a smaller memory footprint and with much faster startup times.

GraalVM native executables in the native Images are a different mode of deployment with strong benefits and limitations. The AOT processing is the pre-condition for turning a Spring based application into a GraalVM native executable. We must need to run the AOT steps before the GraalVM native image tool comes in. This is because GraalVM requires the output of AOT steps mandatorily in order to produce the GraalVM native image. In fact, the native image will only include those artifacts that you tell it to include.

Please note that AOT & GraalVM approaches are only as good as they can be used for a complete stack. They are not good enough in an isolated Spring based application. They really need to work with a complete Spring Boot Stack.

Changes in Core Container

The @Inject annotation comes under the JSR-330 annotations. Spring provides support for JSR 330 annotations since Spring 3.0. Spring Framework 6 onward, it will be found in jakarta.inject.

Similarly, @PostConstruct and @PreDestroy comes under the JSR-250 annotations. Spring Framework 6 onward, @PostConstruct and @PreDestroy will be found in ‘jakarta.annotation’.

Note:  The primary objective of the JSR (Java Specification Request) annotations was to define a set of annotations that address common syntactic concepts and therefore can be utilized by many Java EE and Java SE technologies. In order to know more about JSR, kindly go through JSR documentation.

LocalVariableTableParameterNameDiscoverer is deprecated now.

ListenableFuture has been deprecated in favor of CompletableFuture. See 27780.

SimpleEvaluationContext disables array allocations now, aligned with regular constructor resolution.

Change of HttpMethod from Enum to Class

Spring Framework 6 changed HttpMethod from enum to class.

HttpMethod is no longer an enum. It is now a class. Though the public API has been sustained, some migration might be required (i.e. Change from EnumSet<HttpMethod> to Set<HttpMethod>, use if else instead of switch).

It is obvious that we will need a new build for it, but this was long due.

Web Applications

With the new Spring Framework 6 release, due to the Jakarta EE migration, web servers are upgraded to Tomcat 10Jetty 11, or Undertow 2.2.19 with the undertow-servlet-jakarta. Also, imports from javax.servlet are upgraded to jakarta.servlet. However, in order to generate the latest server, consider Tomcat 10.1 and Undertow 2.3 (Jakarta EE 10).

Spring Framework 6 has dropped several outdated Servlet-based integrations such as, Apache Commons FileUpload, Apache TilesFreeMarker JSP support. Instead, Spring Framework 6 recommends ‘org.springframework.web.multipart.support.StandardServletMultipartResolver’ for multipart file uploads and regular FreeMarker template views if needed. This new version focuses more on REST-oriented web architectures.

Spring Framework 6.0 introduces a change in controller detection for Spring MVC and Spring WebFlux. Spring MVC and Spring WebFlux no longer detect controllers based solely on a type-level @RequestMapping annotation. In previous versions, a class annotated with @RequestMapping at the top level only was registered as handler, even without @Controller or @RestController annotation. With Spring Framework 6, @Controller annotation is required.

Data Access and Transactions

Since the new Spring Framework 6 is migrating towards Jakarta EE, Hibernate ORM is upgraded to Hibernate ORM 5.6.with the hibernate-core-jakarta artifact. It means that if we are directly coding against Hibernate we need to switch from javax.persistence imports to jakarta.persistence.

The corresponding Hibernate Validator generation is 7.0.x, based on jakarta.validation (Jakarta EE 9). You may also choose to upgrade to Hibernate Validator 8.0 right away (aligned with Jakarta EE 10).

CannotSerializeTransactionException and DeadlockLoserDataAccessException are deprecated as of 6.0.3 due to their inconsistent JDBC semantics, in favor of the PessimisticLockingFailureException base class and consistent semantics of its common CannotAcquireLockException subclass (aligned with JPA/Hibernate) in all default exception translation scenarios.

Servlet Mocks Require Servlet 6.0 now

Due to a breaking change between the Servlet 5.0 and 6.0 API jars, the Spring-provided Servlet mocks (MockHttpServletRequest, MockHttpSession) require Servlet 6.0 now. They can be used for testing Servlet 5.0 based code but need to run against the Servlet 6.0 API (or newer) on the test classpath. Note that your production code may still compile against Servlet 5.0 and get integration-tested with Servlet 5.0 based containers; just mock-based tests need to run against the Servlet 6.0 API jar.

What is the Spring Framework release roadmap?

The next Spring Framework release, which is Spring Framework 6.1 GA will be released in the next year i.e. November 2023. On the other hand, there will be two releases of Spring Boot, which is Spring Boot 3.0 & 3.1 till November, 2023. It means Spring Framework will have one release per year, whereas Spring boot will have two releases per year. Below is the roadmap for the same.

Spring Framework 6.0 GA: November, 2022

  • Foundation for Spring Boot 3.0 & 3.1
  • Production ready on JDK 17 LTS
  • Regular stream of 6.0.x enhancement releases

Spring Framework 6.1 GA: November, 2023

  • Foundation for Spring Boot 3.0 & 3.1
  • Production ready on JDK 17 & 21 LTS
  • Regular stream of 6.1.x enhancement releases

Going forward, release roadmap will work in this way.

Spring Framework 6.1 GA: November, 2023

  • Foundation for Spring Boot 3.0 & 3.1
  • Production ready on JDK 17 & 21 LTS
  • Regular stream of 6.1.x enhancement releases

Going forward, release roadmap will work in this way.

 

 

 

close

Leave a Reply

Top