First information on JDK 21: What will the next LTS bring? - JVM Weekly #36
Today we take our first look at the topic of what the next major release of JDK 21 will bring. In addition, interesting materials about JFR and Release Radar collecting news from the past few weeks.
1. The first information about JDK 21
As we all slowly look forward to the imminent release of JDK 20, the list of features coming to JDK 21 this fall is also slowly clarifying in the background.
Let's start with JEPs, which have already been officially proposed as part of the fall release. So all indications are that we will get there a preview version of String Templates. Their goal is to be an extension of Text Blocks, introduced in JDK 15 - String Templates make it easier to fill them (but also regular Strings) with dynamic values.
To better visualize, one example from the JEP:
String name = "Joan Smith";
String phone = "555-123-4567";
String address = "1 Maple Drive, Anytown";
String json = STR."""
{
"name": "\{name}",
"phone": "\{phone}",
"address": "\{address}"
}
""";
It is also possible to pass whole expressions:
int x = 10;
int y = 20;
String s = STR."\{x} + \{y} = \{x + y}"; // 10 + 20 = 30
The whole thing is based on so-called processors, in the above examples STR.
was used, which simply performs interpolations. The JDK itself also introduces a FMT.
processor, which allows for additional formattings, such as defining float
decimal precision. The user will also be able to define custom processors. The resulting mechanism looks really flexible and goes far beyond simple filling strings with variables.
Another addition already announced is JEP 431: Sequenced Collections. Until now, the JDK lacked an interface that could define collections with elements in a clearly defined order, while allowing easy iteration over them forward and backward. For this reason, basically, every existing collection approached the topic differently:
Therefore, a new interface, based on the Deque implementation, will come to JDK:
interface SequencedCollection<E> extends Collection<E> {
SequencedCollection<E> reversed();
void addFirst(E);
void addLast(E);
E getFirst();
E getLast();
E removeFirst();
E removeLast();
}
In addition to better support for operations on the first and last elements, it will also be easier to iterate over the collection in reverse order thanks to the introduction of the reversed()
method.
That's not all, however - all indications are that we'll also get two more JEPs in JDK 21 - Record Patterns and Pattern Matching for switches. As noted by Reddit's /r/java, although both JEPs still remain in Draft, the code examples in them clearly refer specifically to JDK 21. So it seems that the fall will belong to Project Amber.
And while we're on the topic Pattern Matching and record deconstruction - JDK developers don't plan to stop there. Last week Brian Goetz published an analysis of Deconstruction patterns on the possibility of implementing deconstruction of objects other than just records. This document proposes the introduction of Deconstructors, which are a generalization of the solutions created for records. They are to allow destructuring of any class that has them declared - deconstructors must be defined explicitly and require an exact match.
The example below shows what they could look like, although Brian Goetz cautions that all following are for illustration purposes only and should not be considered final or anything.
class Point {
final double x, y;
public Point(double x, double y) {
this.x = x;
this.y = y;
}
public matcher Point(double x, double y) {
x = this.x;
y = this.y;
}
}
Thus, they are supposed to be something like the kinda inverse of constructors - because they are supposed to collect the values of the fields of a given object and expose them as easily extractable from the class.
Just for the record (heh), it is also worth mentioning that JDK 21 will be an LTS (Long-Time Support) release. So let's hope it will be as feature-filled as possible - for it will be the JDK suggested for production use for years to come.
Sources
2. What the JDK Flight Recorder can be useful for
JDK Flight Recorder (the official JVM monitoring application) for a long time "flew under the radar" of most JVM developers, due to the fact that it required a commercial version of the JDK provided by Oracle. While there were companies that had one, licensing model strongly affected both the skill level of programmers (due to poor availability it was difficult to learn how to use the tool) and the interest to invest in learning it (it was all too likely that the next company we would work for would not have access to it). But now that the whole thing is finally in the hands of the community, and we can say that a small, slow renaissance is finally taking place.
Recently, the blog inside.java featured a transcript of a presentation by Oracle's Joakim Nordström, which provides a very practical introduction to how Flight Recorder might be useful for developers. The entire talk focuses on the JFR and its basic components, such as API, available settings, events, types of information available, and metadata and metadata. So in less than 40 minutes, Joakim will show you enough to decide whether JFR should be incorporated into your application.
JFR also has its little heroes outside Oracle, and if the above presentation encourages you to try this tool, the best person to follow would be Gunnar Morling. Can you imagine, for example, that such a Flight Recorder result file format is not officially documented in any way? It is Gunnar who, on the basis of the source code has prepared a full specification of how Flight Recorder works, along with a very detailed diagram, which can now allow you to create alternatives to the original Oracle tools, as well as integrate the whole thing into the whole ecosystem of monitoring tools.
Gunnar's blog is full of great publications showing what a powerful tool Flight Recorder is, such as the relatively fresh text Finding Java Thread Leaks With JDK Flight Recorder And A Bit Of SQL or the slightly earlier Is Your Blocking Queue.... Blocking?. Suffice it to say that it was his publications that got me interested in a tool that I probably wouldn't have touched with a stick before - I heartily recommend it.
Sources
3. Release Radar
Maven 3.9.0
Although successive versions of Maven have gone somewhat unnoticed recently, this still the most popular application-building tool continues to evolve and follow trends. The recent release of Maven 3.9.0 marks an essential step in the project's development - it has dropped support for (much) older versions of the JDK and now requires Java 8. The developers boast that this move has allowed them to update several key dependencies, e.g. Guice or Maven Resolver. In addition, there are also several bug fixes and improvements - you can find the full list here.
The developers warn that this update may cause problems for some plugins due to changes in the way dependencies are handled. In particular, the problem touches the aforementioned Maven Resolver, which means that some plugins may need to declare a dependency on a specific version of plexus-utils
.
Apache NetBeans 17
Does anyone still use NetBeans? If so, a new version of this editor was recently released.
The list of changes is really long, but it lacks something of as much interest as, for example, features coming in each new version of IntelliJ. At this point, the most interesting aspect of the release is that NetBeans is probably the fact it is still being developed. However, If I had to highlight which changes are the most significant from my perspective, the more eye-catching ones would undoubtedly include support for Jakarta EE 10 and PHP 8.2.
jOOQ 3.18
jOOQ 3.18 has been released with several enhancements. One of the key additions is an improved DiagnosticsListener (which provides additional diagnostics for SQL queries). In addition, jOOQ 3.18 adds support for several - vendor-specific - useful SQL/JSON extensions, further implementations of the Query Object Model (QOM) API introduced in jOOQ 3.16, support for Oracle associative arrays, and several improvements for jooq-kotlin
that enable more idiomatic use of that language.
At the very end, fans of reactive programming should rejoice - this release also updates the R2DBC (reactive database driver) version to version 1.0.