The most important reason x86's are relevant today (and why we are stuck with them) is because they run Windows. ARM doesn't need that and, even if it did, Microsoft needs ARM enough they are promising Windows 8 and Office for it.
>The most important reason x86's are relevant today (and why we are stuck with them) is because
they had better price/performance at the start and just plain better performance a bit later. Alpha ran Windows and was a nice CPU. Unfortunately it did _cost_ .
Can ARM run Java for enterprise users? Nehalems with DDR3 have hard time doing it.
There is of course the market for energy efficiency coming with ARM's straight in-order execution, and if we multiply these simple cores, and with programmers and compilers doing better work on parallelization we even can get decent performance, yet i doubt it will beat out-of-order superscalars.
On the other side it isn't [directly] about price, performance or efficiency because it isn't direct competition. x86 run desktops which was explosively growing computing segment of yesterday. ARM runs mobile - explosively growing computing segment of today. The arguments of big iron CPUs vs. x86 back then were similar to the arguments of desktop/server x86 vs. ARM today. These arguments are technically valid, yet they just don't matter today like they didn't matter yesterday as they talk about different computing devices and task they do. The mobile device primary task isn't Excel. It is maps, photos and Facebook/Twitter. This mobile computing looks primitive the way Visicalc looked primitive to the computing of big iron. Yet it is the largest piece of tomorrow's computing and ARM is just more suitable for it than x86 the way x86 was more suitable than Alpha/Sparc/Cray/etc... for desktop.
ARM can run Java, in fact they used to have a (sadly undocumented) op extension called Jazelle which ran common Java techniques JVMs use (such as stuff involved in exceptions or stack management or bytecode decoding/execution).
When using a JVM that is based on ARM's JVM (which does NOT include Android's), a lot of bytecodes directly translated into existing ops and Java ran much faster.
Due to the lack of documentation, open source JVMs (or even non-Java VMs) could not take advantage of it.
However, Jazelle has been replaced with ThumbEE, which does the same thing, but generically so any language that could benefit from it can use it, and it is also documented and FOSS friendly.
Java (->Jazelle RCT, Java over ThumbEE), Perl, and Python have VMs that take advantage of ThumbEE now.
