It hasn't been trivial to get other JVM languages working on Android, and ironically that list now includes Java 8.
Oracle are largely to blame, I suppose.
Tactical choices are constrained by strategic goals.
End users have no use for open source, besides free beer.
Or they could build their own OS's from scratch, as they always have also done, sure; but an important part of Google's strategy, though, was to make the core of Android open source, which they couldn't do if something as fundamental as the basic runtime required a paid license from a third party. And AOSP is -- empirically -- not useless to third party builders without the separately-licensed Google services.
> End users have no use for open source, besides free beer.
Just-for-me modifications are a real thing, if maybe not all that common, so I wouldn't say "no use".
If Google wanted to stay conservative, they could just support Java 8, but if they wanted something considerably superior ... well, Kotlin is not participating here.
But hey, Google sucks so much at programming languages (see Go and Dart) that I don't expect that they do anything that makes sense for developers.
It does contain many features people have been asking for in Java for years, but that Java 8 does not provide, such as: properties, mixins, type inference, pattern matching, operator overloading, etc.
Also, I assume that JetBrains would be open to other features that Google would like in a Java-replacement.
At any rate, all JVM languages, including Scala are going to be limited by the VM and bytecode. So, you'll have to live with type erasure, without your own value types, etc.
I could totally understand that, it would probably their last and only chance to get some users.
I don't want to sound harsh, but their situations must be quite dire right now. The language is still stuck in some 0.x-land (unlike Ceylon), Java 8 shipped with most of their features already, they are unable to compete with better languages (like Scala) and the tooling and IDE situation looks pretty bad, too.
> At any rate, all JVM languages, including Scala are going to be > limited by the VM and bytecode. So, you'll have to live with type > erasure, without your own value types, etc.
Because having a VM with value types and working Generics is such an impossible feat that no one managed to implement it? I guess not.
No one is preventing them from supporting a superset of the class file format which allows value types and better Generics.
I think it's very unlikely that this is in the works since, if it were, you'd expect Google to have thrown significant weight towards kotlin development (https://github.com/JetBrains/kotlin/graphs/contributors).