A New Era For Spring |
Written by Nikos Vaggalis | |||
Monday, 19 December 2022 | |||
The new versions of both Spring Framework and Spring Boot come with new baseline requirements. They also have great new features. Let's look into them. First of all, what are these new baseline requirements? A jump to Java version 17 breaks all ties with the past. This means that since the majority of legacy Java apps are mostly in Java 8 and the newer ones being written at minimum in version 11+, there's going to be some migration pain if you want to consume all the new bells and whistles. While upgrading a Java 8 app to take advantage of the new Spring version might not be realistic, rewriting it or starting a new project from scratch by adopting the new framework is a sensible proposition. If you go down that route you immediately take advantage, not only Java 17 version features, but also those of Jakarta EE 9.1+. However the recommendation is to go straight to the latest version 10 of Jakarta EE. The reason for this is that, as we examined in "Jakarta EE 10 - A New Era For Java On The Cloud", it is focused on the cloud and adopting it enables Spring to target the cloud too. In fact, Jakarta EE underpins many such infrastructure technologies:
For the purposes of the Cloud, a new profile is now being introduced, the Core Profile. It is a profile specifically aimed at lightweight runtimes that are optimized for running cloud-native Java Microservices with a focus on enabling implementations that make use of ahead-of-time compilation. Talking about specs, Jakarta EE 10 is the first release that updates the core specifications since Java EE 8. As such the following specs get all updated: Activation 2.1 (minor release) For Spring that means taking advantage of the new APIs, access to the latest web containers such as Tomcat 10.1, Jetty 11, Undertow 2. 3 and the latest persistence providers such as Hibernate ORM 6. 1. Ah, yes and migrating from javax to the jakarta namespace. Version 6.0 also introduces Ahead-Of-Time compilation, thus enabling first-class support for GraalVM native images with Spring Boot 3. This is important for Spring to establish itself on the Cloud as well as to go Serverless. Previously, you could compile Spring applications to Native Images with Spring Native, which took the pain out of the GraalVM build process. The GraalVM build process, which tries to make the most optimal image possible, throws a lot of stuff out. This could be dependencies, resources or parts of your code. The way to mitigate this is by feeding GraalVM a bunch of configurations files that will cause it to include the extra material in the image. To automate this process you annotate your code with hints in order to direct the Spring AOT plugin to generate those configurations files. However, the Spring Native bundle includes spring-native-configuration which, in Spring Boot's true spirit, handles it for you. It contains configuration hints for Spring's classes and therefore it takes care of the framework without further ado But now with first-class GraalVM support included I don't know if Spring Native would serve any purpose although it might still be useful to pre-Spring 6 installations. And with that addition you might have thought that's the end of the changes. No it's not! There's also early compatibility with virtual threads and Project CRaC ’s checkpoint restore approach for faster JVM startups, aiming to improve Spring's admittedly slow startup time. Project CRaC is one of the three carriages for Java quick start along with the JVM Runtime optimizations and static compilation (OpenJDK Leyden). Well now, there's a new player in town. . As examined in "Google Joins Adoptium - What's The Deal?" Google is already making an impression on the project by, in partnership with Alibaba, kickstarting the Eclipse Adoptium FastStartup Incubator project, aiming to make Java faster by exploring things like class pre-initialization. And that's concludes the major changes. There are many more of a more minor character like: Spring MVC
Observability
General Web Revision
Spring Boot 3 followed along, adopting Java 17 as well. Migrating an app to Spring Boot 3 is necessary if wanting to use Spring Framework 6 since it is now on Jakarta EE 9+ , as such using the jakarta. * namespace. The rest of the changes are support for native images/GraalVM, you can use the spring-boot-native-image-maven-plugin or the spring-boot-native-image-gradle-plugin for that, and enchantments on Observability by adopting the new observation APIs introduced in Micrometer 1.10. This means that you can now watch a Spring application with Micrometer and Prometheus. Spring Boot 3.0 also uses Spring Security 6.0 and will upgrade a number of dependencies and might require work on your end. To migrate Spring Boot 2.x apps there's detailed official instructions plus an experimental tool, Spring Boot Migrator (SBM). What's missing is the planned support for the Java Platform Module System (JPMS);and for the time being it has been left out due to the complexity it introduces. With all that, Jakarta, Spring and subsequently Java are coming aggressively for their Cloud's market share. And not to forget the new possibilities paved by AWS SnapStart going Serverless.
More InformationWhat's New in Spring Framework 6.x Spring Boot 3.0 Migration Guide Related ArticlesJakarta EE 10 - A New Era For Java On The Cloud Google Joins Adoptium - What's The Deal? AWS Lambda Updated With SnapStart
To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.
Comments
or email your comment to: comments@i-programmer.info |
|||
Last Updated ( Monday, 19 December 2022 ) |