Today will be a lot about Kotlin, in the context of two releases – Kotlin 1.7.20 and… JDK 19. Plus an attempt to slim down Java from Brian Goetz and a summary of Microsoft’s activities in the ecosystem.
1. Kotlin 1.7.20 released
It’s been a while since we first reported on the Beta version at the end of July, but finally, Kotlin 1.7.20 is here. Kotlin versions 1.x.20 have always been important, being the last stop before the next “major” release. Does 1.7.20 also bring with it significant changes?
This time, as strong as ever…
Well, because it’s a little hard to talk otherwise about the release of Kotlin when the main novelty is the addition of experimental plugins to an experimental compiler. K2 has thus moved closer towards the production version. The key word here, however, is “moved closer.” I am very much looking forward to K2 and believe that it could be a kind of new quality for Kotlin. However, it would be really hard for me to recommend someone to upgrade the version solely because of this. Still, the support of the aforementioned compiler plug-ins, such as all-open
, no-arg
and Lombok
means that many projects will finally be able to fairly effortlessly verify how well K2 actually works for their use cases. This will certainly give Kotlin developers a ton of valuable feedback.
Of course, as usually is the case with K2, all these novelties, for now, apply only to Kotlin fired on the JVM (by the way, this very edition received in 1.7.20 some other experimental novelties, mainly performance ones). Kotlin today, however, is much more than a JVM. That’s why yet another essential (and yet another under the hood) change 1.7.20 bring is the stabilization of a new memory manager for Kotlin Native. This one had already been tested for several releases, but the developers finally decided it was ready for production prime-time. The new memory management is expected to improve coroutines support significantly, as well as ease code sharing between iOS and Android. So from that perspective, it represents an important milestone for the Kotlin Multiplatform project.
Well, yes, but what will the “ordinary” Kotlin user get out of this release? Well… basically nothing.
No, dear ..<, you are not. But it’s also hard to see you as something that will overturn the lives of programmers, especially since syntactic support for open-ended ranges:
when (value) {
in 0.0..<0.25 -> // first quarter
in 0.25..<0.5 -> // second quarter
in 0.5..<0.75 -> // third quarter
in 0.75..1.0 -> // last quarter <- note closed range here
}
remains an experimental “feature.” The same can be said about data object
, a new data type that differs from the usual object
only in its better representation of toString…. and also remains experimental.
Sources
- Kotlin 1.7.20 Released
- The NEW Kotlin 1.7.20: Unboxing and Review
- NEW OPERATOR in Kotlin (and true open-ended ranges)
2. What does Kotlin have to offer for Java developers in 2022?
For all those who have read my divagations about the new Kotlin release as something strongly negative – I hasten to clarify here. I like Kotlin a lot and regard it as a viable “increment” over Java. The problem is that its developers did such a good enough job in the first few versions that it’s hard to introduce any significant revolution now. Additionally, the project’s developers seem to have fallen into a bit of…. technical debt, hence so many of the new things tend to touch on aspects that are hardly visible to the average language user.
This makes it a long time since we’ve had something in Kotlin that has made any kind of significant impact and hype, and a kind of “runaway” in Multiplatform is also dragging a bit. There would probably be nothing particularly disturbing about this for the language if it weren’t for how strongly it has affected the competition. Especially the closest one – Java.
Lest it would be just my DoomSaying, however, there are more voices like that. At the end of 2019, Jake Wharton – well known in the Android community – published a set of predictions about how quickly Java would be able to catch up with its younger cousin. Based on the JEPs available then, he wondered which of Kotlin’s then-existing advantages would still be viable at the release of Java 19. And since that has just taken place, it’s time for summaries. These, in turn, are very … interesting.
Of all the features discussed in 2019 (Text Blocks, Records, Sealed Classes or virtual threads), the only one that hasn’t been delivered is Local Methods – all the others we can already use in Java. Jake’s text ends on a somewhat positive note (Kotlin, after all, has also introduced some new features since then). Still, it seems to be increasingly difficult to convince Java developers to migrate because the investment in a new ecosystem yields less and less year after year.
And the situation is gaining momentum. Already after the publication of Wharton’s text, Brian Goetz, a regular in these weekly summaries, published a major text with the telling title “Paving the on-ramp”, connected to the possible future of Project Amber. Within the publication, he analyzes what would have to happen to the language to make it more enjoyable for beginners. He discusses an attempt to move on from:
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello World");
}
}
to
void main() {
println("Hello World");
}
So, w could achieve “almost” the maximum simplification of the syntax of the language’s Hello World. As it turns out, this is not something unfeasible – Brian clearly outlines what next steps would have to be taken to eventually reach the goal mentioned above. Along the way, several new language features would have to appear (such as unnamed classes or predefined static imports), and sizable changes would have to be made to the so-called “launch protocol,” a set of rules telling which methods can be the launch point for Java programs.
I recommend reading the publication because it is both accessible and full of interesting details for anyone curious about the process by which the evolution of a language like Java takes place. In addition, the text also helps to understand the ideas behind somewhat lesser-known language features like JShell.
Sources
3. How Microsoft uses Java?
And finally, briefly about the corporate PDF from Microsoft. After all, the Redmond-based company has decided to show off all that it does for the community …
… but also what it takes from it. So we have the opportunity to find out in which Microsoft projects Java is realistically used. It turns out that there are true quite a few. However, the reasons why Java appears in particular projects are more interesting than the mere fact of usage.
Indeed, two patterns can be distinguished. On the one hand, the likes of Bing or Azure went into Java because of the distinctive workload of the projects – both of which are based on ecosystems that require the JVM to some degree or integrate well with it – Kafka, Hadoop, Spark, or Zookeeper are just some of those mentioned in the document. On the other hand, many projects were simply bought with Java on top – LinkedIn, Yammer or Minecraft were based on this technology. This just goes to show how much an acquisition can affect the evolution of a technology stack at a company, even one as large as Microsoft.
Overall, I recommend taking a look if you want a good summary of the scope of Microsoft’s activities in the Java ecosystem – it’s surprisingly broad.