Will Valhalla bring better nulls to Java? - JVM Weekly #33

1. Kotlin 2.0 is coming

It turns out that a lot of changes are coming to the world of Kotlin - at least when it comes to versioning (but not only).

Indeed, the developers have announced that the 1.9 release will be the last of the 1.x line. Version 1.10 will not be released, instead, the whole project will be jumping straight to the 2.0 release. This specific version is going to bring the long-awaited K2 compiler  - "one to rule them all" and is intended to provide a common compilation infrastructure for all potential language targets. This will ensure that Kotlin creators won't have to implement the same compiler functionality for JVM, WebAssembly, or Android each time, which is expected to significantly speed up language evolution. Thus, the change is so big that it was deemed reasonable to properly crown it with a proper bump in versioning.

The change of a "major" version has been able to heavily mess up the ecosystem of many languages, but in the case of Kotlin, JetBrains promises a stable migration process. This is to be achieved through two components. First, the changes motivating the version bumping are taking place under the hood, and the developers deliberately do not plan to introduce any new innovations in the language's syntax in the 2.0 release. They are saving those for the future 2.x releases, which will come after the successful transition to K2. In addition, however, JetBrains benefits from the fact that it controls both Kotlin language and is the main supplier of its tooling. This allows the whole operation to run much more smoothly.

Vertical Integration, a bit like Apple.

Simultaneously with the above announcement, a preview version of the 1.8.20 release was released, which introduces the -language-version 2.0 flag. This one allows you to test the latest changes in the compiler. What's in them? We'll probably return to the topic with the release of the stable 1.8.20, but if nothing changes it will be a release heavily focused on the internals of the language.

Roman Elizarov is already communicating that as soon as they release Kotlin 2.0 and K2 they will move with a kick.

2. MicroProfile, Scala, and Kotlin communities have fun with the Loom project

Some Arount-The-Loom announcements have accumulated so we will devote the whole section to the topic.

Let's start with Helidon Níma, cause the project released the ALPHA4 version last week. I'm not used to informing you about such an early stage of framework development, but this time Alpha is really interesting. This is because the developers of Níma have managed to make quite an achievement, which is the creation of a MicroProfile 5.0 API implementation compatible with Virtual Threads, specifically with the WebServer implementation provided by Níma. This is a huge leap for the project (and actually for the entire community around MP).

Last week also saw the appearance of Prototype Loom-based concurrency API for Scala by Adam Warski, CTO of SoftwareMill. He experiments with the concept of creating a "native" API for virtual threads in Scala, using the language's type system in a way that prevents programmers from kicking themselves in the knee. After all, keep in mind that virtual threads themselves are a fairly low-level API that most programmers will probably use through some abstraction, however.

The article touches on Structured Concurrency, Scoped Values, and makes a comparison of the newly created experimental API (a prototype of which Adam called ox - cOncurrency eXtensions) with existing solutions in Scala. At this stage, as one can easily guess, the libraries that have been under development for many years are much more mature. However, it should be remembered that, as is the case with Reactive Extension, functional code is simply more difficult to understand for the untrained programmer. What Loom, on the other hand, brings is the simplicity of usage, even if its abstraction does not yet have ready-made patterns for all problems.

Presumably, the x-axis could also be labeled as "Burnout Level "

The text itself is great, though, and if you have even a passing interest in functional languages, this will be a great read. The Ox code itself is also available on GitHub, perfect for those who prefer to learn by hands-on experimenting.

And since we have already touched Kotlin today, let's also take a look at how this language is preparing for the upcoming Project Loom launch. I'll admit, that while browsing through its roadmap one looks in vain for virtual threads there, but this may be due to coroutines themselves being flexible enough to run on multiple so-called Dispatchers. This means that you can easily "swap out" the asynchronicity model running underneath. So just as we have a Dispatcher for RX, it is possible to create one for Loom.

I, for a moment before kicking myself in the knee and used my own Coroutine Dispatcher in production.

The topic resurfaced in December in JetBrains' "Talking Kotlin" podcast, where Urs Peter elaborates on it and, despite the ominous title Will Loom Kill Kotlin Coroutines? builds a narrative that in fact, Kotlin will be the first to consume value from virtual threads. After all, we already mentioned that they are low-level features. Coroutines already provide high-level APIs with standardized ways to deal with asynchronous programming - so this is the same theme that runs through the above article on Scala. If you're curious about what advantages Project Loom will have for Kotlin programmers, an article kt.academy appeared Running Kotlin coroutines on Project Loom's virtual threads, showing how you can already experiment with the whole thing today.

Because let's be honest, anyone who has dabbled a bit in bytecode realizes that in fact, Kotlin's had to hack the lack of Coroutine in Java hard - as you can see in the above example.

Sources

3. Is Valhalla going to bring better nullability support to Java?

Finally, we will deal with Valhalla. After a period of silence, the project has started publishing updates again. The latest one is so interesting that, despite the very early stage of discussion, it is worth briefly mentioning here.

One of the features of the language that Valhalla is supposed to provide are Value Types (or whatever they're called in the current iteration). One obvious distinction between "reference types" (i.e., those currently existing in Java) and "value types" is that the latter cannot take null values. Unlike Kotlin, this property is not easily expressed in the language itself. That's why designers for Valhalla are considering introducing a new "nullness" marker for objects.

Because as you can see, the difference is considerable

The new feature is supposed to allow objects to clearly mark whether they allow nullability or not, and keep this information in the runtime. This will help the JVM optimize how they are stored in the heap. For now, there is no proposal for a specific syntax; for simplicity, the developers are using a Kotlin-like syntax in correspondence (Foo! as non-null Foo and Foo? for a variant of Foo or null). However, these are still very early days and the JVM team does not rule out using some kind of annotation @NonNull for this purpose instead.

And - as we've come up with a reference to Kotlin in every other section - it is worth mentioning that other languages using Java as Host Language can only benefit from this change. After all, the developers of the JVM intend to use this marker for better memory management at the level of the virtual machine itself.

The tide lifts all boats.

A valuable discussion about the proposal can be found on Reddit

Sources

Bonus: A report The State of Spring 2022 has been released.

I ran across the report, and there is unlikely you will find anything truly revolutionary in it, but I will share with you two facts that caught my eye.

First of all, 35% of Spring users say they are using a reactive version of Spring. It is also interesting to note the growth (though not a huge one) of Spring's use in Serverless solutions.

The Spring community (at least that part that has heard about them) also reacts enthusiastically to new developments in Java. 90% who are aware of Project Loom would like to be able to use it in Spring, and GraalVM is on the radar as much as 98%. The enthusiasm is there, let’s see how many will actually succeed in getting native images into production.