Java programs do not run in a VM any more.
Patent nonsense. The JIT compiles methods that have run several thousand times, and it uses the tracing information it collects during bytecode execution in order to do so. That's why it methods in the server VM require more
calls as bytecode before they're ever compiled. And it's still designed to back out to bytecode whenever it needs to, such as in the face of new overloads appearing.
JVM Bytecode is starting to resemble something like an IR, but that doesn't mean it is one.
Okay, you're right because there is an interpreter in HotSpot. That said, the majority of the time it won't be in use and really doesn't need to be used at all. Its not that much different than having a scripting engine and 1000 is a small number in the computer world. Of course that is how HotSpot treats Java bytecode. Not every platform, device, or compiler does it that way. You wouldn't just port HotSpot and call it good.
For future reference I will try to look to see if the interpreter works on an instruction level or method level. For tracing information you only need to watch which branch is taken, so you do not necessarily need to emulate a CPU to get that information. How IR is used does in one part of one program does not change the fact it is IR. LLVM has an interpreter and bytecode may be used as IR for Android and GCJ.