Also, this is nice: "Java is an interpreted language. The JVM is the Java interpreter."
Anally nitpicking at that sort of thing does nothing to further discussion, and I hate to see it here so often.
That was actually my point. When someone doesn't know the technical meaning of a phrase, they generally assume the literal and broad meaning of it. The target audience for the original blog post presumably falls mainly into that category.
And just because something is not of particular interest to you doesn't make it anal nitpicking that "does nothing to further discussion."
Technically this is true. The JVM interprets Java bytecode in the sense that it translates the bytecode into machine language on the fly.
Basically, I'm in favor of a law that says "If you want to use the word compiled or interpreted in your blog post, you have to write a programming language first." That is the project you need to do to understand compiled vs. interpreted.
edit: Of course, it would be possible to build a machine that actually executes JVM instructions directly. It would also be possible to build such a machine for JavaScript, but if someone asks you whether JavaScript is an "interpreted language," the answer would still be affirmative, even if there are cases where it's not true.
Even in the case of instructions which do map directly to hardware ops, the CPU is still doing branch prediction and prefetching, which implies that the code is being examined (i.e., "interpreted") before being executed.
I'm not trying to say that performance isn't better when funneling native instructions down to the CPU; rather, just that it's worth remembering that there's really no such thing as "[running] on bare metal" any more, at least on a modern x86 ISA system.