[java] Was there a practical reason Java wasn't designed this way?

What do you mean by "install the program on the computer in its native environment"? JIT compilation is already happening.

Maybe I misunderstand how the Java Virtual Machine works. How I understand it is that it loads its byte code and translates each instruction into an instruction that the machine can understand. I thought it was that translation that causes Java to be relatively slow.

What I was referring to was creating an installer program that acts as a compiler and installer for the program. It would just translate the code only once during installation and then the program would act as just a regular native program on the machine.

Something like this?

Quote:

Original post by ManaStone Maybe I misunderstand how the Java Virtual Machine works. How I understand it is that it loads its byte code and translates each instruction into an instruction that the machine can understand. I thought it was that translation that causes Java to be relatively slow.

You're incorrect. Read up on JIT compilation. There's no one-to-one mapping, and the compiled code is cached and recompiled as necessary to optimize performance.

Quote:

How I understand it is that it loads its byte code and translates each instruction into an instruction that the machine can understand.

If does.

Quote:

Original post by ManaStone I thought it was that translation that causes Java to be relatively slow.

No, it's poor development practices with no regard for efficiency that cause most of the bloat. Sun's JVM itself is probably the fastest general purpose VM right now, excluding memory cache issues, it rivals native C performance and even exceeds it in some cases.

Fun fact - Apollo 11's on-board computer had a virtual machine.
"The AGC also had a sophisticated software interpreter, developed by MIT, that implemented a virtual machine with more complex and capable pseudo-instructions than the native AGC. They were used for navigational computations where greater precision was required. Interpreted code, which featured double precision scalar and vector arithmetic"

Quote:

What I was referring to was creating an installer program that acts as a compiler and installer for the program. It would just translate the code only once during installation and then the program would act as just a regular native program on the machine.

Many issues:
- Some applications allow on-the-fly code reloading and compilation, where source isn't known at some previous compile time. Most app servers work this way.
- JVM itself is tiny, but standard library is huge, some 40MB. Due to many licensing issues and proprietary code, this could not be distributed in a way suitable for static compilation - it would require such compiler to provide their own version, which wasn't possible until couple of years ago
- Java has fallen out of favor on desktop, and on servers robustness counts more. The VM has proven itself in this regard, so there was no need, either for efficiency or any other reasons.
- All mainstream languages in use today are dynamic and interpreted on-the-fly, either via JIT, AST parsing or some other technique. Very few find this to be a problem, so static compilation has fallen out of favor compared to flexibility dynamic languages offer.