This release adds a significant number of new features and improvements and, thanks to CRaC, faster warm up times.

There's been a lot of news and developments around the Java ecosystem lately. Java 21, Virtual Threads, OpenJDK builds with CRaC, are just a few.

Vendors and applications are playing catch up,as we've examined in a number of articles:

• Liberica Joins The Java CRaC Train
• AWS Lambda Adopts Java 21
• Helidon Microservices Framework Version 4 Reaches General Availability
• Azul To Tackle Java's Warm Up Issues

Now it's time for VMWare to get on board by getting Spring Boot up to par to the latest developments, with the release of Spring Boot version 3.2.0.

First off, this new version is fully compatible with Java 21 while maintaining the JDK 17 as a baseline.

Then the biggest adoption it did from JDK 21 , a game changing one, is that of Virtual Threads. As we've seen, Helidon v4 by switching from Jetty to Nima can now harness in full the capabilities of Java 21’s virtual threads.

Helidon's official blog release states :

Since each request now operates within its own dedicated virtual thread, it can freely execute blocking operations, such as interfacing with a database or another service, in a straightforward synchronous manner without the risk of obstructing a platform thread and depriving other requests of resources. This eliminates the necessity for complex asynchronous code to create a low-latency, extremely concurrent service.

Spring wise, does it mean that it will render Reactivity with WebFlux a thing of the past? As far as the non blocking IO aspect of Reactivity goes, surely will replace it and make a difference too as the code to write will be much simpler. Saying that, Reactivity however means much more than that. It means also the caller/subscriber controlling the volume of the data returned by the publisher/database, aka backpressure, streaming results, and of course the advantage of Reactive programming versus the imperative model. Therefore Reactive frameworks still hold value.

Unlike Helidon's reliance on the Nima server, Spring Boot's adoption of Virtual Threads relies on Jetty and Tomcat. To enable it on Tomcat you must use the new VirtualThreadExecutor in order to configure Tomcat to use virtual threads which come bundled with Tomcat 10.1.10+, while the application needs utilizing JDK 21 and enabling the spring. threads. virtual. enabled property.

The next best thing after Virtual threads is the Initial support for JVM Checkpoint Restore (Project CRaC).

Lately a lot of investment has been put into making Java faster to start. This has to do that with Java re-emerging as a major player in the sector of Microservices and Cloud Native applications, due to some great and new language features, optimized JDKs along with frequent release rates;therefore performance should follow along.

The JVM is notorious for its hefty requirements in startup times. The main reason for the slow startup is that it takes much time to load, link, and initialize classes. Of course we are talking micro-seconds here but the delay can make a difference when trying to spin VMs on the Cloud and run Microservices.
There's a few takes at speeding it up already, not taking in account GrallVM and Spring Native.

Project CRaC stands for Coordinated Restore at Checkpoint. It is an API that helps to coordinate the JDK and an application's resources under a checkpoint/restore mechanism. It allows applications to, for instance, close open files, dump their cache, and snapshot the required state for them to come alive when restored back. As such the primary aim of the project is to offer a standard mechanism-agnostic API to notify Java programs about the checkpoint and restore events.
That was a solution instilled into the JDK.

The concept of check pointing and restoring images has already been put to test under AWS Lambda SnapStart with the results being very encouraging. As we examined in AWS Lambda Updated With SnapStart, the way SnapStart works is that:

the function’s initialization is done ahead of time when you publish a function version. Lambda takes a Firecracker microVM snapshot of the memory and disk state of the initialized execution environment, encrypts the snapshot, and caches it for low-latency access.

When your application starts up and scales to handle traffic, Lambda resumes new execution environments from the cached snapshot instead of initializing them from scratch, improving startup performance.

The CRaC API gives developers a way to react to the snapshotting process with pre and post hooks, in case they want to create unique data directly in a Lambda function initialization phase. They can use the beforeCheckpoint hook to run code immediately before a snapshot is taken, and use the afterRestore hook to run code immediately after restoring a snapshot. This helps in deleting any unique content before the snapshot is created, and restore any unique content after the snapshot is restored.

As such the Java managed runtime uses CRaC to provide that hook support, therefore the runtime contains a customized CRaC context implementation that calls the Lambda function’s runtime hooks before completing snapshot creation, and after restoring the execution environment from a snapshot.

So to cut a long story short, this means faster warm up times for Spring Boot v 3.2.0 too. To use it, you need a JVM which has CraC built in; that is Liberica, Azul or AWS.

While Virtual Thread and CraC support are the two most important changes, the new version comes with other minor as well, such as :

Jetty 12
Spring Boot now supports Jetty 12. Jetty 12 supports the Servlet 6.0 API, aligning it with both Tomcat and Undertow.

H2 Version 2.2
Spring Boot now uses version 2.2 of H2 by default.

RestClient Support
Spring Boot 3.2 includes support for the new RestClient interface which has been introduced in Spring Framework 6.1. This interface provides a functional style blocking HTTP API with a similar to design to WebClient.

Support for JdbcClient
Auto-configuration for JdbcClient has been added, based on the presence of a NamedParameterJdbcTemplate. If the latter is auto-configured, properties of spring. jdbc. template. * are taken into account.

Keeping the JVM Alive
There’s a new property called spring. main. keep-alive. When set to true, the JVM is kept alive, even if all other threads are virtual (or daemon) threads.

SSL Bundle Reloading
SSL bundles can now be automatically reloaded when the trust material changes.

Of course various bug fixes and deprecations. Full release changes available at the project's GitHub repo.

More Information

Spring Boot 3.2.0 available now

Related Articles

Liberica Joins The Java CRaC Train

AWS Lambda Adopts Java 21

Helidon Microservices Framework Version 4 Reaches General Availability

Azul To Tackle Java's Warm Up Issues

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

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info