[pjmlp]

Plenty of other platforms do support bytecodes, JIT and AOT on the same toolchain.

So they could keep the WORA story and still offer AOT as an option, which actually most commercial JDKs do.

Just Sun was against providing it at all on Java SE, but they actually supported it on Java Embedded.

[j-g-faustus]

I was commenting on "why did they design Java that way in the first place", as opposed to (say) Go.

I agree that once the primary use of Java moved outside the browser, there was no particular reason to not give the option of AOT too. I'm not sure why Sun was so adamantly opposed to the idea.

If I recall correctly, Sun really wanted to stick with JIT on Java Embedded too, they just couldn't get it to run fast enough on embedded hardware. For desktop and servers, they considered bytecode interpretation and JIT "fast enough".

[pjmlp]

Sure and actually that is where mobile OSes are moving.

We now have bitcode on iDevices, DEX on Android and MSIL/MDIL on WinRT.

Still, both iDevices and Windows Store take, what I consider the best approach, to do AOT on the store for each supported target.

As Google found out, using AOT on the device doesn't scale. I just don't get why they went back to an overly complicated architecture of Interpreter/JIT/PGO → AOT, instead of following the same path as the competition and serve freshly baked AOT binaries.