I think this depends on how we define “better”. Kotlin is still only generating Java 8 bytecode right? Some could argue that Javac 11 → 13 does a better job implementing/compiling closures maybe?? and making use of JDK API enhancements.
It is not clear to me that Kotlin wants to be “the best” bytecode compiler for the JVM (better or match javac on Java 13+).
I feel the same and this is my biggest concern. Lack of detail around the JVM & mixed Java lang as a primary target for Kotlin. Targeting JDK 13+ and keeping up with the progress on the JVM/JDK/Java. As a developer that expects to have multiple JVM languages needing to work together for a very long time (mixed Java and Kotlin) it isn’t clear where Kotlin wants to be with Loom, Valhalla, compiling newer bytecode etc.
Java 9-15 has almost nothing new from the point of view of bytecode. Some new optimizations in VM, but you will get them with even old bytecode.
Kotlin does not fully utilize dynamics from java 8, and I think it will be fixed after 1.4.
I hope that too.
Unfortunately, there isn’t any JetBrains official confirmation, nor a shared roadmap.
I opened an issue two years ago without any significant update.
We are discussing how to support features introduced in old Java versions like 9, but are the same time we should ask yourself when to deprecate Java 6 support.
Java 8 is a good starting point due to the multi-release jar supported in Java 9+.
Back to the thread, I think that catching Kotlin is not in the Java’s roadmap, nor that awaiting Java is in the Kotlin’s roadmap.
Java 6 support is needed for Android programming RN, and for Android programmers that was one of the major selling points for Kotlin.
You have a wrong feeling about Android. They did not have a battle about the Java language’s syntax. It does not belong to Oracle. They had a battle over the implementation of some interfaces and methods that are used both in Oracle’s JVM and Dalvik VM (~ Android’s JVM). Now, Android switched to ART. You could use the Java language syntax at all times. But, apparently Kotlin syntax is better, which is, fortunately, compilable to a JVM/ART bytecode. So, both Java and Kotlin are to stay and that has nothing to do with Oracle.
They’ve already decided to go with decorators instead, which should hopefully cover that usecase
Can you link to some reference about that? Or do you mean Roman’s blog post?
It was part of a talk by Roman this year about multiple receivers https://youtu.be/0FF19HJDqMo?t=795
I personally don’t think this completely covers the use case of 87 though, but it’s at least an improvement in the right direction.
It is not decided since there are questions about signature transparency for multi-receiver decorators, but the concept itself looks nice.
Yeah I meant as like the concept itself seems to be what they have decided at or like at the very least they aren’t going to go with keep 87 and instead will choose a more general solution
Would it be difficult to add destructuring/matching for “when” selector? I have code with so many “when” branches.
Yes and no. Adding this specifically is probably not that hard. That said there are a lot of design decisions that go into a simple feature like this (just look through the discussion about collection literals). One concern is that you have to support such a feature for the future and it can make it harder to implement other features. If you mess up simple destructuring/matching for “when” it will be much harder or even impossible to implement real pattern matching.