JVM Weekly #1 – Spring Boot, Leyden, Structured Concurrency
After nearly 90 issues that were released in Poland, we decided to try the international version. This issue is a test episode, with which I would like to gather feedback on how interesting this form is for you and whether it is worth continuing :) Feel free to read and comment.
1. Spring Boot 2.7 released
In line with the invaluable Spring calendar, last week, we had the release of the Spring Boot 2.7, which was accompanied by the release of new versions of several other Spring projects. That's why today's issue will start with a look at what's new in the last 2.x releases before Spring Boot 3.0.
There's a lot and a little here at the same time. Sure, things like support for the increasingly popular Cache2k or easier registration of Jackson Mixins are quite interesting additions, as well as native support for Podman, an alternative to Docker (the better alternative - finally with 🦭 instead of 🐳 in the log). However, there's no denying that this is clearly the calm before the storm, and we'll get bigger changes only in the autumn, along with the release of "Spring Boot 3.0." This impression is not likely to be washed away by the last of the big news in version 2.7 - AutoConfiguration and metrics for Spring for GraphQL.
Also associated with the latter is the biggest of the accompanying new Spring Boot releases - Spring for GraphQL stable version 1.0. There's a lot more going on in this one than in the "main" release:
Significance expanded the number of annotations available to the user
Improved parameter validation
batch query and interceptor support introduced
QueryDSL support
HTTP, WebSockets, and RSockets client
And that's not all anyway. Spring for GraphQL 1.0 is, in my opinion, the most interesting spring-connected news since the first Spring Native preview was released.
What else accompanies the new Spring?
Spring Security version 5.7 introduces several new features to support OAuth and SAML mechanisms, and provides RequestAttributeSecurityContextRepository and SecurityContextHolderFilter to make working with SecurityContext easier. A special DSL for CORS header handling has also been introduced
Spring Data version 2021.2 brings the ability to define the ClassLoader you want to use, support for value converters based on specific fields in a class, new capabilities for entity projection, and major and minor changes to basically every provider to specific databases.
Spring LDAP version 2.4.0 has received repackaging that makes it easier to use with a system of modules
Spring Session, Spring Batch, Spring Hateoas also received minor tweaks in the form of dependency boosting and error correction.
Sources
2. Preparation for the Leyden Project
Recently, everyone's got their hands on JVM performance. In April, Project CRaC got a big announcement; at the beginning of May, there was a new update to Project Liliput, and now Project Leyden is back, which I haven't heard about for a good year.
What is Leyden? As a concept, we're talking about an initiative quite similar to GraalVM and contains a ton of points in common with it. It is intended to create a specification for Static Images. A static image is a standalone program that cannot load any external entities on the classpath, nor generate new bytecode at runtime. This is a very big limitation compared to regular Java applications, so what do we get in return? These two allow achieving "freezing" a set of classes in the target application for its entire lifecycle, meaning that already at the compilation level, anything unnecessary can be knocked out, thus reducing both image size and runtime (as part of the so-called Ahead-of-Time (AoT) compilation process).
Now, almost two years after the original Call-For-Discussion and feedback gathering, the developers are getting to work on an initiative based on community-generated use cases. However, there is already talk that one of the implementers of the specification could be the GraalVM.
Sources
3. Structured Concurrency in Incubation
And to top it off, a feature that just went into incubation that is part of Loom and is a natural complement to Virtual Threads... the long-awaited Structured Concurrency.
What is structured concurrency? Unless one wants to try to dig into some dusty papers from the 1960s (because you can find anything there), its roots should be sought in a 2016 blog post called "Structured Concurrency" written by Martin Sústrik - the creator of ZeroMQ. In it, he presented the concepts of encapsulating concurrent execution threads with blocks of code with clear start and end points that would guarantee that all threads finish their work before exiting a given block. This type of approach greatly facilitates reasoning about code and error handling.
The idea probably would never have gained as much popularity had it not been for Roman Elizarov, the architect of the Kotlin coroutines, who decided to put it to practical use in the design of the mechanism. The effects turned out to be so good that there was a big change in thinking throughout the JVM, and - for example - the original version of the Loom project basically went to the trash, and the final variant is already a solution fully compatible with Structured Concurrency.
If the above reminds you of try-with-resources, introduced in Java 1.7, then you have very good associations. Loom designers decided to base their version of structured concurrency on this construction familiar to Java programmers:
Response handle() throws ExecutionException, InterruptedException {
try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
Future<String> user = scope.fork(() -> findUser());
Future<Integer> order = scope.fork(() -> fetchOrder());
scope.join(); // Join both forks
scope.throwIfFailed(); // ... and propagate errors
// Here, both forks have succeeded, so compose their results
return new Response(user.resultNow(), order.resultNow())
}
}
In the above example, the try block will automatically "clean up" all threads created in it in case of any problem. The life cycle of the whole is also clearly defined, and the results are convenient to collect because the whole sample behaves basically like a synchronous code.
Unlike virtual threads themselves, which are currently as Preview, JEP 428: Structured Concurrency is in incubation and unlikely to make it into JDK 19, much less in a stable version into JDK 21, the next LTS. What the developers want to accomplish now is to get community feedback to refine the target API.
Bonus: Intellij Idea's new look
And finally, a trifle in the "gossip and rumor" category.
The Intellij Idea backlog has received a really big redesign, involving a refresh of the entire editor
I know that this is a news like "new Facebook design," but as there are a lot of changes, I decided to share them with you. More details and looks of specific components can be found here.