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.
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.
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".
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.