After a week’s break, today we’ll focus mainly on Spring I/O, hooking you up with the interesting topic of containerized Java along the way.
1. Java will(?) get a dedicated performance profile for containerisation
Many times I encounter some skepticism when it comes to industry reports presenting industry statistics, especially connected to programming languages. “And what’s the point”, “bad methodology”, “unrepresentative group” are just some of the comments that can be found online. At the same time, however, it is sometimes worthwhile to devote a little more space to this type of research. A few weeks ago I had the opportunity to share with you two reports, from Vaadin and New Relic, respectively. While the first one has probably already been forgotten by everyone (Enterprise Java, which it was devoted to, is not the most “sexy” topic in the world), the publication of “The State of Java Ecosystem 2023” turns out to be likely to have slightly wider repercussions than anyone could have expected.
The people in charge of Java at Microsoft have recently announced that they are working on a JEP to introduce Ergonomics Profiles into the Java Virtual Machine (JVM). This feature would allow Java to have two different configurations: a ‘shared’ profile, designed with the assumption that the JVM must share resources with other processes, and a ‘dedicated’ profile for systems that can give most of the resources exclusively to the JVM process. This move is motivated by the aforementioned data from New Relic, which shows that more than 70% of the JVMs they monitor are running in dedicated environments such as containers, very often without any configuration, and therefore very inefficient.
The proposed ‘dedicated’ profile aims to enable the JVM to use available resources more efficiently, especially in dedicated environments. For example, unlike the current ‘defaults’, where the JVM’s maximum heap size varies between 25% and 50% depending on the available memory size, the new profile could increase the default heap size allocation to 60%-70%. What’s more, it would also include other heuristics helping in GC selection, defining active processor counts and the size of the JVM’s internal thread pools. In addition to introducing the first two profiles mentioned, JEP is expected to introduce frameworks to extend OpenJDK with more profiles. For now, however, we’re waiting for more, as the work has yet to be announced to the wider community.
But the “Ergonomic Profiles” were just a bonus (although we won’t get away from the topic of containerization, it will come back to in that edition). Let’s move on to the real fresh meat.
2. Virtual Threads, CRaC, GraalVM, Spring Boot 3.1 – what interesting things Spring I/O 2023 has brought to the table
I know everyone has probably forgotten by now, but Spring I/O 2023 took place in mid-May. For those (like me, unfortunately) who didn’t have the chance to visit sunny Barcelona, recordings of talks appeared on the official conference channel. So finally, now that everyone can watch the conference from their room, we can concentrate on looking at what was presented.
Let’s start with the Keynote, which can be treated as a kinda Table of Contents for the whole conference. During it, Juergen Hoeller – Spring Framework’s project lead – announced the upcoming releases of Spring Framework 6.1 and Spring Boot 3.2, as well as new features that will come with it, such as virtual threads (min. by working on modernizing the servlet stack). Also on stage were Spring developer Sébastien Deleuze and Alina Yurenko, Developer Advocate of GraalVM, who talked about how Spring Boot Native Image was a great revolution for the project in order to run faster and use less resources. We had also an opportunity to see Spring Cloud Function, Spring’s attempt to enter the Serverless market. Sébastien additionally talked about CRaC and the new capabilities coming with it. Also on stage was Josh Long, Spring Developer Advocate, who showed the new capabilities of Spring Boot 3.1.
And now we’re going to “unpack” these topics properly, because each of the these covered at the Keynote got its own followup.
For example, during Spring Framework 6.1: Infrastructure Revisited (my favorite session) he presented plans for Virtual Threads integration in Spring Framework, with a fair amount of detail. Plenty of space was devoted to Jakarta EE 21 and Tomcat 10, and how these projects will enable faster integration in Spring. Juergen Hoeller also leaned into the coexistence of Virtual Threads and Spring WebFlux. Once again, we get confirmation that Reactive Programming and Virtual Threads (although they have elements of intersection) will rather be parallel alternatives to each other. Don’t expect Virtual Threads to replace Reactor – Spring MVC will instead allow integration of both approaches. Overall, a very good session if you are curious about what benefits the introduction of Virtual Threads into Spring will bring, at a slightly deeper level than “it will be faster.”
It doesn’t end there, however, about Spring Framework 6.1: Infrastructure Revisited, as the second half of the session was devoted to the integration of CRaC (Coordinated restore at Checkpoint) into Spring Framework. I won’t introduce you to CRaC itself anymore – I feel like I do this in every other edition, so feel free to at least to the previous one. Juergen Hoeller showed what additional challenges implementing CRaC into Spring brings, especially from a Bean lifecycle perspective. However, this is information more for those who are interested in what’s going on under the hood, since from the point of view of a Spring user and in most applications, no additional steps should be needed, and the whole thing is expected to hit our hands as early as Spring Boot 3.2, integrating Spring Framework 6.1.
Final versions of both projects should be released later this November. The new features will require some updates (JDK 21 for Virtual Threads, CRaC is currently supported only by OpenJDK Azul), but Spring Framework 6.x itself is expected to remain compatible with JDK 17+.
As every reader of this newsletter probably remembers, CRaC is also available as a crucial part of AWS Lambda SnapStart engine – the entire project had a dedicated session AWS Lambda SnapStart: Dramatically reduce cold starts for your Java functions.
Also an interesting extension of the Keynote was Going Native: Fast and Lightweight Spring Boot Applications with GraalVM by Alina Yurenko. The presentation is a great introduction to the differences between JIT and AOT, as is the case with Spring Framework 6.1: Infrastructure Revisited going a little deeper into project specifics. For example, the presentation spent quite a bit of time on the advantages of GraalVM that aren’t talked about much, such as the resilience of the application to various potential attack vectors. A sizable portion of the presentation was devoted to a Live Demo showing what working with Native Images in Spring Boot really looks like. There was even room to present future plans and directions in which to develop am GraalVM along with the entire platform. And since we started the whole thing by showing the potential impact of research in the community on the future of Java, I’ll toss a link to the result of a survey conducted among the GraalVM community. Alina even mentioned it during the Keynote, which once again shows that your voice matters.
That’s just to wrap up the whole thing nicely, let’s also take a look at what has already hit our hands – new versions of Spring-connected projects.
The main course is certainly Spring Boot 3.1. A key theme of the new release is containerisation, and this is from a variety of perspectives.
The first huge addition is support for TestContainers in Spring. Probably everyone using this project in their Spring Boot testing was strongly confused at this announcement, but we are actually talking about a completely new level. This is because AtomicJar, in cooperation with Spring, has introduced the possibility of using TestContainers for development as well. It looks a bit like working with Docker Compose, except that the container configuration is in Java, not YAML. The whole integration is based on the concept of
ConnectionDetails objects – beans that provide connections to external services. If defined in the project, they will take precedence over connections “outside”, making it possible, for example, to redirect connections to the local version of Postgres, put up in the background using TestContainers.
Secondly, a new library
spring-boot-docker-compose has been introduced, which takes care of handling Docker Compose files in the project. For those who prefer to use YAML rather than Java, when the application starts up, it looks for the Docker Compose file and its configurations, and then creates a container for us based on TestContainers. Additionally, it attaches all necessary configurations to our local application. This means we can run
docker-compose.yaml in our project without having to configure it in
In addition, there have been a slew of dependency updates, such as Hibernate 6.2, Mockito 5 and Jackson 2.15.
In addition, minor updates have also been given to projects such as:
However, the changes taking place are somewhat minor, so I encourage you to check the original Release Notes.