Why Do Interpretors Compile the Code Everytime a Program is Run?

My question is about all interpreted languages, but to illustrate my point better I will use Java as an example.

What I know for Java is that when programmers write their code they have to compile it in java byte codes which are like machine language for a universal java virtual machine architecture. Then they can distribute their code to any machine which runs the Java Virtual Machine (JVM). The JVM is then just a program that takes the java byte codes and compiles them (for the specific architecture) every time I run my program. From my understanding (please correct me if I am wrong here) if I run my code the JVM will compile it on the fly, my machine will run the compiled instructions, and when I close the program all the compilation work will be lost, only to be done again, the second time I want to run my program. This is also the reason why generally interpreted languages are slow, because they have to compile every time on the fly.

However, all of this makes no sense for me. Why not download the java byte codes on my machine, have the JVM compile them for my specific architecture once and create an executable file, and then the next time I want to run the program, I just run the compiled executable file. In this way the promise of java: "write once, run everywhere" is still kept but without most of the slowness of interpreted languages.

I know that while compiling the JVM does some clever dynamic optimizations; however isn't their purpose only to compensate for the slowness of the interpretation mechanism? I mean, if the JVM has to compile once, run multiple time, then wouldn't this outweigh the speed-up of the optimizations done by the JVM?

I suppose there is something obvious that I am missing here. Does somebody have an explanation?

This is incorrect:

The JVM is then just a program that takes the java byte codes and compiles them (for the specific architecture) every time I run my program.

The JVM contains a bytecode interpreter and also an optimizing bytecode compiler. It interprets the bytecode of your program and only compiles bytecode to native code if necessary for performance reasons, to optimize "hot spots" in the code.

To answer your question of why not store that compiled result, there are several issues:

• It would need a place to store it.
• It would need to handle splicing in the compiled parts with the parts that weren't worth compiling (or compile the whole thing).
• It would need a reliable way of knowing whether the cached compiled code was up-to-date.
• The optimized, compiled code for a program run with arguments A, B, and C may not be optimal if the program is run with arguments X, Y, and Z. So it would have to handle that possibility, either second-guessing the original compilation or remembering the arguments (which would be imperfect: if they were filenames or URLs, for instance, it's not going to keep their contents), etc.
• It's largely unnecessary, the compilation doesn't take all that long. Compiling bytecode to machine code doesn't take nearly as long as compiling source code to machine code.

So I think the answer is: It's difficult and error-prone, so the cost isn't worth the benefit.