You're confused on several points. First, Java VMs don't "generate bytecode": if they have JITs, they generate machine code. Otherwise, they just interpret byte

You're confused on several points. First, Java VMs don't "generate bytecode": if they have JITs, they generate machine code. Otherwise, they just interpret bytecode. Second, you're confusing OpenJDK-the-set-of-libraries with Hotspot-the-VM. OpenJDK probably isn't a disaster for performance: not because it's good, but because Harmony was abysmal. (Count the allocations inside String.format.) Switching from ART to Hotspot is not a clear win. ART does AOT compilation (at least some of the time), is integrated with the system runtime (doing a compacting GC pass on app switch, for example), and interacts properly with Android's zygote-based start scheme. (It doesn't, for example, COW away all the memory benefits as a naive fork would.) Both ART and Hotspot have pretty good code generators and allocators. There's no reason to support that the latter would be a better choice, technically, than the former. Google seems to agree, since ART development is ongoing. Please read more about VM implementation schemes instead of continuing to make unfounded assertions (like "Java is based on the idea of a JIT" and "virtual method calls are slow without a JIT").