Jump to content
  • Advertisement
Sign in to follow this  
ManaStone

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

This topic is 2909 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Let's say instead of just providing a virtual machine, Java also gave us the option of making an installer that would run on a virtual machine and install the program on the computer in its native environment to make it faster. Are there any drawbacks or problems with this approach that I am not seeing?

Share this post


Link to post
Share on other sites
Advertisement
What do you mean by "install the program on the computer in its native environment"? JIT compilation is already happening.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!