JDK 21 Strikes Back: Stable Virtual Threads and Generational ZGC – JVM Weekly vol. 128.

1. JDK 21 Strikes Back: Stable Virtual Threads and Generational ZGC

It was only a week ago that we touched on what an interesting release JDK 21 promises to be, and already we have to return to the topic because it would be a sin not to report on more potential improvements coming to the fall LTS. Indeed, we have received two more big announcements on the subject.

Let’s start with the biggest bombshell, which is the fact that stable Virtual Threads are coming. On the one hand, it was to be expected (the second Preview was really cosmetic), on the other, I was not sure whether we would have to wait for the stabilization of the remaining features of Project Loom and the developers would simply drop it from the fall LTS. The machine has started, however – the official JEP Draft has been released, and with minimal changes. The only major one is the removal of the ability to oupt-out of having thread-local variables. As writes Ron Pressler, the functionality was misunderstood, and it was never in the developers’ plans to remove ThreadLocal entirely, as such an option might imply. For communication clarity, it was decided to simply drop this feature.

And while JEP remains a Draft for now, if accepted, Virtual Threads will come out of Preview and become a stable feature in JDK 21. Now we are waiting for the announcement of  Structure Concurrency Preview and we will have “Loom Bingo”.

The second of the new JEPs, this time qualified as a candidate for JDK 21, is JEP 439: Generational ZGC. Probably most of you have heard what the generational hypothesis is, but as my daughter is about to turn two, I need to practice ELI5 (Explain me like I’m Five):

Imagine that you have a lot of toys in your room, some of which you just got, and some of which you have had for a long time. You may play with new toys often, but eventually they will get boring and stop being fun (this is all too true…). On the other hand, the toys you’ve had for a long time may not be played with as often, but since you haven’t gotten bored with them yet for a year, it is likely that won’t happen for a long time into the future.

Generative garbage collector works in the same way. It divides objects in memory into two groups, young objects, and old objects. Young objects are those that have just been created, and old objects are those that have been around for a while. The garbage collector checks young objects more often because they tend to “die young,” meaning they are created and then quickly become unused. Old objects are checked less often because they are more likely to still be needed. By dividing objects into generations, the garbage collector can optimize its memory management and reduce the time and resources needed for garbage collection.

ZGC – Garbage Collector, which is used to clean up even terabytes of memory without an interruption of more than a few milliseconds. ZGC is described as a low-delay GC, which can be considered a kind of state-of-the-art as far as the Java VM is concerned. However, it is not without flaws – ZGC’s design is very complicated, even without Generations. That is why its first (current) version is single-generation.

As a result, the ZGC has always had a problem with the so-called purification of the young generation. However, the developers announced from the very beginning that they would not stop there, and now we get our hands on JEP 439: Generational ZGC. Interestingly, up until now, there was no intention to maintain two versions of ZGC – there was a plan that once the generational version was implemented, the original implementation would disappear. It turned out, however, that while the new ZGC should be a better solution for most use cases than the non-generational ZGC, there are still cases where the latter works better. Therefore, temporarily, the developers have decided to keep both ZGCs, with the idea of getting rid of the original version in the future. This is a very unusual situation, and now I am curious how bad the performance of the generational ZGC is in the mentioned “certain cases” that the developers decided to keep two variants.

If you’d like to learn more about ZGC itself, depending on what form best appeals to you, I recommend the video presentations Java’s Highly Scalable Low-Latency Garbage Collector: ZGC or the podcast Towards Generational ZGC.

Sources

• JEP 439: Generational ZGC
• JEP draft: Virtual Threads
• Java’s Highly Scalable Low-Latency Garbage Collector: ZGC
• Towards Generational ZGC.

Discover more IT content selected for you

In Vived, you will find articles handpicked by devs. Download the app and read the good stuff!

2. How is the community using Jakarta EE?

In September 2022, OmniFish and OmniFaces conducted a survey on Jakarta EE, asking questions related to its use, application servers and APIs. Last week, its results appeared, containing some interesting observations.

Before I start sharing the survey data, a small disclaimer – the data comes from 720 responses collected from the Jakarta EE community. So we are talking about a relatively small set on the one hand, but on the other – already statistically significant. However, due to a specific research group (it can be assumed that the survey included those most engaged users of Jakarta EE), the data may be distorted. Thus, one should look at them with a grain of salt and treat them rather as a curiosity. However, they still tell us a bit about the sentiment of the Jakarta EE community.

The data shows that despite the rolling transition of libraries and projects to Jakarta EE 10, it is still Java EE 8 and Jakarta EE 8 that are the most widely used versions. However, it must be admitted that the adoption of the latest Jakarta is quite promising – the Jakarta EE 1- is currently in third place, ahead of Jakarta EE 9.

And when it comes to application servers, here we have a head-to-head race between WildFly and Payara Server. WildFly is still at the top of the pile, but Payara has been winning the heart of the community quite effectively recently. Both projects have a minimal percentage of dissatisfied/neutral users, and in both cases, there is a significant majority of these, who speak of the products in superlatives

On the other side of the pile, meanwhile, are WebSphere and WebLogic.

I personally, however, was most interested in questions about MicroProfile. As in other years, only a minority used MicroProfile APIs, but the percentage that uses these APIs is growing every year. In 2018 it was 16%, in 2020 32%, and in 2022/2023 already 36% – so there is a clear trend. The survey also shows that the workhorse is Quarkus – it is declared as the product used by more than 50% of MicroProfile users. So Quarkus is clearly gobbling up more and more communities under it, and the gap between it and second-ranked WildFly is widening even further. What is interesting here is the low position of Helidon MP, which has been overtaken by both OpenLiberty and Payara Server/Micro. For how much is being said about the project itself, it’s pretty clear that it’s being treated more as an experiment – at least by the Jakarta EE community.

From my perspective, the most interesting topic related to MicroProfile is the sentiment of the community toward merging the project with Jakarta EE. It turns out that users do not have separatist tendencies and almost 70% would like to see both projects migrate. This bodes well for the future, especially considering MicroProfile’s adoption of MicroProfile 6.0 introduced in Jakarta EE 10 Core Profile, which already happened after the results of this survey were collected.

Finally, once again I want to note that the survey may be biased toward more active OSS developers. Therefore, OmniFish plans to conduct the next version of the survey in cooperation with the Eclipse Foundation.

And while we’re on the subject of Jakarta EE, given that we’ve already had a couple of videos in this article, I’ll toss in another one – Has the J2EE vs Spring Infinity War reached an End Game? A short history of Java for the enterprise -covering the historical interplay between Spring and Java EE. The whole thing gives you a better understanding of the dependencies linking the two platforms, and how they have influenced each other over the years. It should be of interest to anyone who would like to know the roots of the most important (I don’t think we need to be afraid of that statement) projects of the Java ecosystem.

Sources

• Jakarta EE Survey 2022/2023 – Results
• Has the J2EE vs Spring Infinity War reached an End Game? A short history of Java for the enterprise

Discover more IT content selected for you

In Vived, you will find articles handpicked by devs. Download the app and read the good stuff!

3. Release Radar: Kotlin, Hilla

Kotlin 1.8.20-RC

Kotlin has released a preview version of Kotlin 1.8.20-RC. I don’t usually write about test versions, but acct Kotlin 1.x.20 is always an interesting release, deserving its own mention, even still at RC stage.

Interesting changes also appeared in the context of the K2 compiler. It got support (for now as a preview) for a serialization plugin and an Alpha version of the compiler for JS IR. What’s more, the new approach to the incremental compilation is now available by default, meaning that users no longer need to specify kotlin.incremental.useClasspathSnapshot=true in their gradle.properties to enable it. In terms of interoperability with Java, the language itself will get experimental support for the AutoCloseable interface. We’ll also receive Base64 encoding in the standard library.

The release also includes (for now in an experimental version) a new “target” for the language – Kotlin/Wasm. Admittedly, this is not the first time we can compile Kotlin to WebAssembly – until now, however, it was done via Kotlin/Native. The new approach (thanks to the omission of LLVM from the stack) is supposed to provide faster compilation, while also providing better interoperability with JavaScript. By the way, the Kotlin team has decided to revise the list of platforms supported by Kotlin/Native and deprecate some of them (e.g. wasm32 itself).

Vaadin Hilla 2.0

About a year ago, Vaadin unveiled Hilla, a new web framework for Java developers that makes it easy to put up a “full-stack” application, one having a Spring Bot-based backend and a TypeScript frontend. Previously known as Vaadin Fusion, Hilla has several aces up its sleeve, such as a unified configuration for Java and TypeScript and a rich set of UI components. The whole thing positions itself as a competitor of the better-known JHipster.

Last week saw the release of version 2.0 of the project, which includes new features such as an improved TypeScript generator, support for web sockets and GraalVM Native Images, as well as simplified theme creation and a new SSO Kit to quickly add single sign-on capabilities to Hilla applications. The new release is built on Spring Boot 3, Java 17 and Jakarta EE 10.

Finally, it’s worth mentioning that the developers are already announcing Hilla 2.1, which is expected to be released in June 2023 and will include better support for forms, further improvements to the SSO Kit, and helpers for CRUD application development. Hille deployment to AWS Lambda is also to be introduced.