They are using a modern JDK on Android. The standard library is literally OpenJDK, and the runtime is the excellent ART JVM, which has super-fast GC and tons of mobile-specific optimizations (like zygote space support and switching to a different GC when the app goes into the background). IMHO, you really don't want HotSpot on mobile. ART is good work.
The runtime prevent the support for modern JVM features such as value types (see my comment above).
Google might duplicate all that work (but how much late they will be before it divide the Java world?
Switching to a unified jvm and improving it through collaboration is the way to go.
I am talking about C2 JIT support and other sota GCs.
ART has an increasingly growing technical debt.
No support for constant dynamic so no support for the upcoming pattern matching.
No support for sub 1ms GC
No support for the already available Vector API.
No support for value types.
No support for generic specialization.
No support for Loom.
ART is NIH and support with Java and Kotlin will explode into two worlds, the Android obscolete world and the modern, feature complete and optimized world.
ART has custom improvments? Fine that's good, now let's gradually port them to openjdk (or a light openjdk fork). No custom improvement is gonna outweight the need of interoperability (and the order of magnitude performance improvement from the above features)
ART is an AOT so I wonder if the android team has considered switching to GraalVM instead of hotspot, the transition might be easier.
Please Google, it's time to show technical excellence.
If you think ART is an AOT system, you might want to refresh your understanding of the system. ART has had a JIT for a long time now. Sure, HotSpot might have some features ART lacks, but ART has features that HotSpot lacks, so it's a wash. (And ART already has sub-millisecond GC pause times.) It's good and healthy for a language to have multiple implementations and there's no obligation whatsoever on the part of the Android people to switch to Oracle's JVM.
"But as long as your system isn’t heavily over-provisioned, you can expect to see average GC pause times of around 0.05ms (50µs) and max pause times of around 0.5ms (500µs)."
https://malloc.se/blog/zgc-jdk16
Sure, HotSpot might have some features ART lacks, but ART has features that HotSpot lacks, so it's a wash.
The ART features are not exposed to the language design. The JVM features in addition to the order of magnitude performance impact it will have (cf previous comment) needs to be supported in order to maintain interop with future JVM languages versions. (cf previous comment)
It's good and healthy for a language to have multiple implementations no it's much healthier to have one that reap most of the benefits through collaboration. Hence why Android try to merge its patchset in the Linux kernel instead of duplicating it's million commits.
Sure, HotSpot might have some features ART lacks, but ART has features that HotSpot lacks, so it's a wash.
Technical excellence unfortunately isn't an obligation. Or at least until the system becomes unsustainable (Cf interop) but then when it comes it is too late.
