However it is a subset as usual, and most likely because they are already starting to feel that Kotlin also needs those Java libraries which are leaving Java 8 behind, unless they feel like rewriting Maven Central universe into Kotlin.
But yeah, I agree with you, they really should have gone with possibly a simpler JIT compiler and an alternative GC implementation that is more conservative in memory usage.
The issue isn't even converting JVM bytecodes into DEX, other compliant Java implementations for embedded do similar approaches, see PTC and Aicas.
The issue is how they have stagnated Java support on purpose as means to push Kotlin, they aren't being innocent by using Java 8 samples against Kotlin features.
And the whole but Oracle doesn't cut it, given how dependent Kotlin is on the whole JVM ecosystem.
Also the code is not just AOTed, Android is using profile guided AOT. After several days of usage, the code is AOTed with the profile collected from previous runs.
See how little everyone cares on the JVM, it is just another guest language alongside Scala, Clojure and Groovy competing for attention.
- What do they win by pushing Kotlin against Java (for reasons that are not also beneficial to developers)? The word "agenda" makes it seem like they have evil intents
- Doesn't Kotlin depend on the JVM, and so wouldn't it benefit from an upgrade
- Isn't Kotlin a programming language that uses the JVM and the Java standard library anyway? (I saw a bit of Kotlin, I contributed a small patch to QKSMS, it seems it is a bit like Groovy in that it is an alternative syntax but is essentially Java with some syntax sugar and some additional classes to make some tasks easier)
I understand that Kotlin may not directly benefit from the new Java language features, but it seems like it would benefit from all the other advances.
(I'm not defending Google, I don't like them)
InteliJ/Android Studio, Gradle and Maven Central libraries.
Kotlin/Native was so well done that they had to reboot the effort.
If they cared about so much, they should have migrated to Dart instead.
Also the Java codebase is significantly slower because raw Hibernate is terrible and should never be combined with JSF.
Meanwhile with grails your only performance worry is that each field plugin template is its own class, which puts immense pressure on the class loader which has to do the non envious job of loading a thousand classes.
Despite significant amounts of indirection and excessive use of hidden reflection to abstract over entity/domain classes, the parts I expected to be slow are never the ones you would expect. CompileStatic, etc is almost never worth it.
Groovy competes more with Ruby than with Java.
They will never replace Java on the Java Virtual Machine.