Last week was full of news related to Kotlin. As a result, our focus this week narrows down specifically to this language in our latest edition.
1. The release of Kotlin 1.9
Let’s start with the biggest announcement – Kotlin 1.9.0 has been released, offering significant improvements to the new K2 compiler in addition to new features.
The K2 compiler for the JVM has gone from alpha to beta, so it is entering final testing ahead of Kotlin 2.0 – the developers encourage us to test our own builds It is worth noting, however, that when using the K2 compiler with the kapt annotation processor plugin, despite setting languageVersion
to 2.0, kapt will continue to use the old compiler, automatically switching to 1.9 and disabling some version compatibility checks. These checks are disabled only for kapt jobs, while all other compilation jobs continue to use the new K2 compiler.
To start experimenting with the K2 compiler in your project, it’s best to set Gradle properties kotlin.experimental.tryK2=true
, and the whole command looks like:
./gradlew assemble -Pkotlin.experimental.tryK2=true
This one not only sets the language version to 2.0, but also updates the compilation result data, giving access to information about where K2 has realistically been used.
In addition to K2 itself, one of the most important changes is a significant reduction in the size of WebAssembly compilations; a basic Hello World example in WebAssembly reportedly takes up ten times less space than in Kotlin 1.8.20. And speaking of WebAssembly, Kotlin 1.9.0 significantly improves WASM JavaScript interoperability, encouraging a move from Dynamic
to JsAny
type. If you want to try how it all works in practice, Kotlin Playground, meanwhile, now allows you to test WebAssembly compilations online as well.
There have also been a few changes to the language itself, the biggest of which is probably the stabilization of the .entries
properties. It is now available for enums as a more efficient alternative to the .values()
method:
enum class Color(val colorName: String, val rgb: String) {
RED("Red", "#FF0000"),
ORANGE("Orange", "#FF7F00"),
YELLOW("Yellow", "#FFFF00")
}
fun findByRgb(rgb: String): Color? = Color.entries.find { it.rgb == rgb }
You can find all the changes, as usual, in the original announcement and the accompanying video:
2. Kotlin Notebook launch
Diving into a bit of foundational knowledge( particularly for those who haven’t collaborated with DataScience teams, who are usually the most adept with this subject) – programming notebooks are tools that integrate code, visualizations, and explanatory text in a single, interactive, dynamic document. They are primarily utilized in data mining, providing a lively programming environment where developers can instantly prototype their code and observe real-time results, accompanied by illustrative annotations and visualizations that record their ideation process. The leading solution in this arena is Jupyter Notebook, but it’s receiving competition from various quarters – even from some rather unexpected contenders.
Indeed, the revelation of the Kotlin Notebook plug-in for IntelliJ IDEA was a highlight of KotlinConf, and last week it was officially launched. One of its advantages over Jupyter, at least from the vantage point of IntelliJ enthusiasts, is its robust integration with the IDE, while simultaneously maintaining compatibility with the Jupyter ecosystem. This is made possible by its support for the Jupyter-standard .ipynb
file format, enabling native rendering on platforms like GitHub and JetBrains’ own Datalore. Going above and beyond the typical Notebook capabilities, this plug-in simplifies the use of dependencies by offering various methods to incorporate external libraries into a project using the %use
directive.
Just yesterday, I explored the solution firsthand and, having a history with Notebooks, I must acknowledge the impressiveness of the Kotlin implementation. Everything appears to function seamlessly right from the start, and the foundation is the openly available Kotlin Kernel, compatible with standard Jupyter as well. Thus, contrary to prevalent practices, the Kotlin realm doesn’t impose Vendor Lock-in, which is rather refreshing.
How the whole thing looks in action is well shown in the video accompanying the launch:
3. The set of official Kotlin educational materials
Early education of users is crucial. It’s a widely acknowledged fact that early exposure of home users to pirated Windows software played a significant role in cementing Microsoft’s dominance in the PC market, while Autodesk’s strategy of offering free software to engineering students ensured its solutions became the industry standard. Similarly, the Kotlin team has placed education at the forefront since its inception. They are arming educators with the necessary tools and resources to nurture the forthcoming generation of Kotlin programmers, thereby tackling the classic conundrum of the chicken and the egg.
A pivotal part of this initiative is a rich compilation of resources, free to access, structured into a semester-long course titled “Programming in Kotlin”. I check this course, having been developed by a team of specialists over nearly a year, and I think it’s truly full of knowledge and practical exercises. It spans from fundamental aspects of Kotlin to advanced topics, including parallel and asynchronous programming, as well as testing. Importantly, these resources are designed to evolve alongside Kotlin, thereby mitigating the maintenance need and the risk of teaching outdated versions of the language.
I confess, I once aspired to curate a workshop or course on Kotlin for a study group from my Alma Mater. However, the sheer magnitude of work involved became a deterrent, causing the plan to fall by the wayside, as the day-long undertaking appeared overwhelming. After all, the course from JetBrains was purportedly developed over a year. Now, armed with these official resources, I believe that the initiative could be significantly simplified.
4. The official Kotlin driver for MongoDB
But lest you think I’m just rewriting JetBrains’ Feed, there’s one more little gem at the end from outside the Kotlin steward’s main offering. MongoDB has announced the release of its own official Kotlin driver.
On the one hand, it’s not that the new solution opens the door to some new types of applications, because the possibility of using MongoDB in Kotlin applications has always been there (about some alternatives, by the way, in a moment). But at the same time, Kotlin is a language so different from Java that using solutions prepared for it always involves a sense of a certain “Frankenstein effect.”
After all, the driver for Kotlin allows, for example, the use of Data Class when returning objects from MongoDB, a key feature of the new driver is also comprehensive support for kotlinx.serialization
and the bson-kotlinx
serializer, as well as Coroutine. In the case of the latter, however, you have to be careful, because you know, databases don’t like too much concurrency. Looking through the project’s documentation, there are quite a few asynchronous calls in it:
- any variants of
collect
method, - All operations in the
MongoCollection
class, so CRUDs and their Bulk variants startSession
,abortTransaction()
andcommitTransaction()
and several others.
Before we wrap up, it’s noteworthy to mention alternatives like KMongo (an unofficial yet fairly popular Kotlin wrapper over the Java driver) and of course, the official MongoDB Java driver, for comparison’s sake. KMongo offers coroutines support and includes a DSL that accommodates MongoDB idioms in Kotlin. However, being a third-party library, it has occasions lagged (and possibly still does) in adopting MongoDB’s new features. The MongoDB Java driver, on the other hand, boasts expansive documentation and a larger user base, but it falls short in providing an idiomatic API for Kotlin. Therefore, I wouldn’t be astonished if transitioning to the official driver pops up on numerous tech-debt backlogs.