Kotlin 1.8 is a phantom release – JVM Weekly #120

1. Kotlin 1.8 – The Phantom Release

Kotlin 1.8 is a strange Kotlin release. Initially announced back in November 2022, it finally came out for a giggle just before New Year’s Eve, on December 28. And that probably would have closed the case (the new version finally appeared), but new Kotlin releases have always been accompanied by a post on the (silent since mid-December) official language blog run by JetBrains, video tutorials, and generally a fair amount of additional material. Not this time.

At first I thought that such would simply appear at the beginning of January, but we are already halfway through the month, and here still nothing. And the whole situation is topped off in a funny way by searching Kotlin 1.8 on Google. In one of the top positions there is a page is.kotlin.released.info, which shows Kotlin’s 1.8 release date as…. April 2023. It’s not an official site but adds to the general impression that this new Kotlin release is some kind of…. abandoned. However, Kotlin 1.8 has been released, so we can take a look at what interesting things it brings.

As usual, we will focus here mainly on the changes concerning the JVM flavor. Let’s start with the fact that the new Kotlin is the first version with support for Java 19. The lower limit of support has also been moved. If you have been using Kotlin in environments where the maximum acceptable version of Java Runtime was version 1.7, I have bad news for you – as of version 1.8, the minimum supported version of the JDK is also 1.8 (at least it’s easy to remember). This allowed, among other things, to speed up the reflection mechanism. As part of the code cleanup, the old JVM IR (intermediate representation), already dormant since Kotlin 1.5, was also removed.

Kotlin also got a new debugging flag – -Xdebug. Its role is to disable some of the optimizations made by the language’s runtime, making it difficult to understand the code’s behavior, e.g. when executing coroutines.

I’m a simple guy, but I’ll admit that out of the entire release, I was most captivated by Support for Lombok’s @Builder annotation. When I first migrated from a large project written in Java to Kotlin, it was the lack of support for @Builder from Lombok that was the most time-consuming manual work. In retrospect, he admits that this annotation is not needed for anything in Kotlin. Still, the lack of its support made it very difficult to migrate projects heavily based on Lombok gradually.

In fact, however, the integration with Gradle has seen the most changes. Indeed, Kotlin has received full support for the functionality provided by Gradle 7.2 and 7.3. There’s a lot of it, so those interested please refer to the relevant section of the official release notes.

Other things, such as slight changes to the standard library, are more like details. So I have a feeling that Kotlin 1.8 is unlikely to write itself into the wider consciousness, except perhaps to Swift/Objective-C programmers – those languages are said to have received a much better compatibility mechanism.

Interestingly, the silence mentioned at the beginning of the article applies not only to the latest Kotlin release, but also to the project’s Roadmap, which also received its update in December 2022. Priorities don’t change – the new K2 compiler and the stabilization of Kotlin Multiplatform Mobile continue to take center stage. However, there are a few new items, such as the public release of a plugin for K2 into IntelliJ and support for third-party library developers. They are to receive KDoc enhancements and official guidelines for APIs, covering, for example, good practices for creating multiplatform projects, rules for publishing artifacts, or ensuring backward compatibility.

To close the Kotlin section already and enter 2023 on a positive note – the official line-up of speakers for KotlinConf 2023 has appeared. So if you’re thinking about heading to Amsterdam in April, you can now check out who you’ll be able to listen to there.

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. MicroProfile joins with Core Profile

While Kotlin 1.8 is still a leftover from 2022, this week saw the first major release of 2023 – MicroProfile 6.0. This one, in addition to the standardization of a new set of APIs, brings a much-anticipated sorting out of what the project’s relationship with Jakarta EE currently looks like.

Along with Jakarta EE 10 came the so-called Core Profile, a set of APIs providing the minimum necessary set of functionalities needed for creating microservices in Java. This sounds very similar to the goal set by the developers of MicroProfile, so from the beginning, we wondered how the appearance of the Core Profile would affect it. Some form of synergy seemed very natural here, but at the same time, there were clear messages that two initiatives should not be expected to merge into one. Their creators, however, assured that they remain in constant contact with each other and on friendly terms.

And now with the release of MicroProfile 6.0 we find out how the two standards will be intertwined. So far, MicroProfile’s strategy has been to pick for itself from Jakarta EE those APIs that the project’s developers thought would be most useful to the MP user. In the case of MicroProfile 5.0, it was thus:

• Jakarta Contexts and Dependency Injection (CDI)
• Jakarta Annotations (JPA)
• Jakarta RESTful Web Services (JAX-RS)
• Jakarta JSON Binding (JSON-B)
• Jakarta JSON Processing (JSON-P)

Since the release of MicroProfile 6.0, the project has made an alignment with Jakarta Core Profile. This means that instead of having a dependency on individual APIs, it will depend on the whole Profile, and the following APIs (in addition to already being part of the MicroProfile) will also be added transitively:

• Jakarta RESTful Web Services
• Jakarta Interceptors

For understandable reasons, the minimum version of Jakarta EE supported by MicroProfile is now Jakarta EE 10.

In addition to the above, MicroProfile 6.0 has also changes related to Observability, forced by the actions of “external entities.” The organization developing the standards for Tracing – the tracking of individual events within an application – is the Cloud Native Computing Foundation (CNCF for short). Several competing projects have been developed under their umbrella over the years, such as OpenCensus and OpenTracing. The latter, by the way, ended up in MicroProfile as the MicroProfile OpenTracing API.

CNCF early last year, however, decided to abandon OpenTracing development in favor of OpenTelemetry, which is a slightly broader project. As a result, the MicroProfile OpenTracing API ceased to be supported. Its replacement is MicroProfile Telemetry Tracing, implementing the OpenTelemetry-derived Tracing standard.

Significantly, OpenTelemetry also introduces its own standard for metrics, but which MicroProfile has chosen not to support, relying instead on proprietary MicroProfile Metrics. This leads to bizarre situations where projects like Quarkus, for example, wanting to fully support the OpenTelemetry standard are forced to abandon incompatible MicroProfile Metrics – you can read more about the situation here. So I suspect that this is not the end of the changes and we are in for further evolution of the MicroProfile/OpenTelemetry relationship in the future.