JVM

What does GraalVM for JDK 21 have in common with the rabbit from the Cave of Caerbannog? Both surprise with their power – JVM Weekly vol. 150

Today we continue with topics from last week – JDK 21 and GraalVM for JDK 21, but also a lot of other announcements related to Graal. Surprisingly, not only GraalVM this time.

Article cover

1. JDK 21: Still a Buzz in the Ecosystem

It’s only been a week since the new JDK 21 was launched, but there is already bunch of new publications covering it’s features. Let’s review the new articles that have been published since then.

Let’s dive into the subject of virtual threads, a topic that has been at the forefront of many recent discussions. We’re increasingly encountering resources that provide us with a more in-depth understanding of this subject. Just last week, we received an official guide from Oracle, which provides an overview of techniques and best practices for Virtual Threads. This excellent introduction also dedicates ample space to structured concurrency – a subject that isn’t as extensively discussed elsewhere. The value of virtual threads is further highlighted in a new article by Quarkus, which focuses on examples of their application in basic CRUD operations.

Let’s be honest: that’s how most of us will use them.

The following text is a review titled Java 21: The Nice, The Meh, and the … Momentous about the new Java. The author, Cay Horstmann, examines the new features in JDK 21, pointing out the significant enhancements from Java 17. He focuses on the practical implications of these features for developers, stressing the importance of virtual threads, which he believes address the complexities of asynchronous programming. While the other features are beneficial, any particular one doesn’t seem to be compelling enough to warrant an update on their own. However, considering the array of new features and numerous bug fixes, Horstmann concludes that upgrading to Java 21 is a wise decision, particularly for those grappling with or contemplating reactive programming. Overall, this is an insightful analysis of the new release, and Horstmann’s viewpoint is worth considering, even if it isn’t particularly revolutionary.

We will discuss the subversiveness in another publication, where Stuart Marks discusses his favourite feature of JDK 21, specifically, the ability to search Javadoc by URL. This feature was initially introduced in JDK 19, but it became popular with the launch of JDK 21 – even though it’s not truly LTS. Previous versions of Javadoc supported searching, but the newer JDKs enable the creation of URLs that directly lead to search results. Marks passionately explains how this feature enhances the use of documentation, facilitates scripting, and simplifies access to information – he provides several examples in the text.

We also received, as a standard companion to new JDK, a text by Sean Mullan dedicated to significant updates in the security field of the new Java. These enhancements encompass a new API for the Key Encapsulation Mechanism (KEM) for Post-Quantum Cryptography (PQC), an implementation of HSS/LMS signature verification to safeguard against quantum computer attacks, and support for various PBES2 password-based cryptography algorithms. The release also introduces improvements to the PKI by adding root CA certificates and enhancing time limits for OCSPs, certificates and CRLs. Moreover, the default Diffie-Hellman group size for TLS has been expanded and XML Signature now supports the EdDSA algorithm with new system properties and security measures.

And to conclude, both Amazon’s JDK 21 and BellSoft have released their distributions of JDK 21. However, I’m still awaiting Temurin, which currently only offers EA Builds.

However, as I’ve spoiled last week, the introduction of JDK 21 was paired with another, corresponding release.

Building tension!
Discover more IT content selected for you
In Vived, you will find articles handpicked by devs. Download the app and read the good stuff!

phone newsletter image

2. What are the similarities between GraalVM for JDK 21 and the rabbit from the Caerbannog cave?

In addition to the launch of JDK 21 (which we are all experiencing), Oracle has launched a new GraalVM version for the mentioned JDK 21.

One of the key enhancements, in line with the new JDK, is comprehensive support for virtual threads. The Native Image build process has also been refined, introducing class instantiation strategies, support for JFR events, and several minor developer experience enhancements, along with a number of new configuration flags. The entire GraalVM SDK has been restructured for improved modularity, dividing the project SDK into org.graalvm.nativeimage, org.graalvm.polyglot, org.graalvm.word and org.graalvm.collections, while ensuring backward compatibility.

Moreover, the efficiency of Native Image has been enhanced once more. Applications that run with GraalVM Native Image, fine-tuned with profile-guided optimisation (PGO) and G1 GC, demonstrate superior throughput compared to those operating with JIT and the C2 JIT compiler – thus, debates about JIT being more efficient in the long term are no longer relevant. Despite this sweet deal, it’s important to note that PGO is only accessible in Oracle GraalVM (previously known as Enterprise Edition). On this note, I have some encouraging news – the project’s FAQ has been revised, providing a significant amount of clarity. Based on suggestion from Thomas Wuerthinger (the head of GraalVM) on project Slack channels, and following my discussion with legal team I cooperate with, it appears that Oracle GraalVM is now indeed suitable for use in SaaS applications.

I note, however, that “The above does not constitute legal advice, only personal opinion. Please contact your own legal department before use”.

Another enhancement includes support for the JEP 338: Java Vector API, which is still in Preview. This allows numerous JVM operations to be converted into native CPU instructions. Interestingly, this feature is activated by default, but can be turned off using the -Dgraal.OptimizeVectorAPI=false option.

GraalVM has now incorporated support for the ARM Pointer Authentication Code (PAC) mechanism on compatible hardware. This security feature aids in reducing return-oriented programming (ROP) attacks by checking the authenticity of a function’s return address. This feature can be accessed using the -H:EnableCFI option.

This is not the end of the story, as the new version of GraalVM introduces significant updates to the multilingual runtime environment, Truffle. Truffle is a framework that enables the creation of programming language interpreters that are optimised for GraalVM’s Just-In-Time (JIT) compiler, enabling them to achieve high performance. A key feature of Truffle is that it allows language developers to focus on the semantics of the language itself, while the optimisation aspects are automatically handled by the framework. Additionally, Truffle-based languages can be easily integrated, allowing different languages to work together in a single runtime environment

Truffle is now unbundled from the GraalVM JDK, which allows for independent downloadable interpreters for languages like JavaScript, Python, Ruby, Java on Truffle, WebAssembly, and LLVM.. In addition, the previously required gu tool is no longer necessary, as all GraalVM languages (in both native, pre-compiled and JVM-based versions) are now accessible in Maven Central. This simplifies the process of embedding languages into Java applications. More information can be found in the post Truffle Unchained.

And it doesn’t stop there – Oracle has begun to organize the tools around GraalVM under the unified label: Graal Stack Components. This includes GraalVM, Graal Cloud Native, and GraalOS. We’ve previously discussed GraalVM, but now it’s time to examine the two other components.

And as you were wondering where the rabbit in the title of this text came from – as the animal in the above screenshot is the Grail Stack mascot, the Beast from the Caerbannog Cave immediately popped into my head (Monthy Python and the Holy Grail, as if anyone wasn’t familiar with the classic). But that my associations go in strange directions, you’re probably used to by now.

Graal Cloud Native (GCN) is a unique version of the Micronaut framework’s module set, complemented with the necessary libraries. It has been endorsed with a reference solution for microservices development in GraalVM. These modules are designed from scratch to be compiled with GraalVM Native Image, producing native executables suitable for cloud applications. This means they start instantly, provide full performance from the get-go with no warm-up time, and consume less memory. GCN provides modules that offer platform-independent support for essential cloud services like object storage, secret management, streaming, and tracking. This enhances application development versatility and reduces dependency on a specific cloud provider. A list of modules is displayed in the screenshot below:

The GCN also incorporates project development tools and an extension to VS Code – GraalVM Tools for Micronaut.

That’s not all, however, as during Oracle Cloud World 2023, Oracle presented GraalOS – the last addition to the Graal Stack Components. This is a runtime for cloud environments, designed to enhance the performance and efficiency of Serverless features. By utilizing the ahead-of-time (AOT) compilation provided by GraalVM, GraalOS transforms applications into independent native executables, removing unused classes, methods, and fields. Furthermore, similar to AWS SnapStart, GraalOS is anticipated to address the ‘cold start’ issue that arises when a function is initially invoked after a period of inactivity. It is also expected to have the capability to ‘freeze’ state at any given moment.

GraalOS is set to become the runtime environment for Oracle Cloud Infrastructure Functions. This makes it an intriguing choice for those interested in launching Graal-based serverless functions. It’s worth noting that AWS Lambda already lets you operate GraalVM as part of what’s known as Custom Runtime. However, this essentially involves running a container with a GraalVM application. GraalOS offers a way around this layer, removing the need to run a container and initialize the JVM.

It should be noted that currently, the function is not yet available for testing. However, you can register for early access. I have already did that and am looking forward to experimenting with the solution.

If you’re interested in following the development, GraalVM for JDK 21 had – similar to JDK itself – a public release stream. To truly experience the vibe of this new release and to learn about the new features directly from the source, I encourage you to watch. You’ll discover several additional new capabilities that I haven’t mentioned in the text.