Some of the stuff you can do on the JVM, yes.
Java? Definitely not.
Java certainly isn't.
Or, as people say, it's kludges all the way down.
It would need to be really inelegant to warrant a comparison with the x86...
Not that much, and not that inelegant ... at least x86 evolved a lot since 8086. The JVM itself evolved only in the internal architecture, but the bytecode itself is almost the same since Java 1.
The best VM for multiple language will soon prove to be LLVM, only because it makes your code cross-platform, while being low-level enough and not being strangled by a standards body.
It's actually easier to build a compiler for LLVM than it is for the JVM ... you might not go at first with a generational GC, and the speed might be terrible ... but at least you have room to grow ...
I have yet to see a language on top of the JVM beat LuaJIT2 (even Java itself can hardly beat it in simpler benchmarks). And the optimizations in Java7 can be achieved today in Java6 (with lots of workarounds, of course).
If you start with a can opener and attach it seats, engine, wheels, transmission and a steering wheel, all in ways it can still be in your kitchen and open cans, is it a car or a can opener? That's an x86.
I am not saying the JVM is the VM to end all VMs. It's just that it's nicely done. Much unlike the x86.
But, albeit we could discuss about stack based vs register based VM instruction set design, some of the limitations of the JVM are not inherent to its design, but rather to the inability to evolve.
Who's going to introduce bytecode extensions to the JVM now? And correctly manage the upgrades, backward compatibility process etc.
Mature products sometimes have this kind of issues. But, who knows, perhaps there will be a time frame when such a change will be welcome (along with java7 closures?) by the community, even if causing some migration problems.