What are the advantages of using Virtual Machine compilation (eg. JVM) over natively compiled languages?

Question

I\'ve heard that the advantage of java is that people can write code, compile it for the JVM, and run it anywhere. Each person just needs a JVM app for their platform.

Answer 1

Portability mostly. The same Java binary can run on Linux/Mac/Windows. Plus SPARC/PPC/x86/x86-64/ARM/MIPS etc. Read: same binary. No recompilation needed. :)

Answer 2

I think the point is that on java you can do useful things that are portable, too. In C and C++, you sometimes end up having to do pointer arithmetic and worrying what sizes ints are (vary by OS and CPU) and such. There are fixes in the standards for dealing with that in a portable way, but java has been designed with this in mind from the start. There is another benefit of the JVM, I think. Things like jython and scala are able to use the vast java libraries (and any other available java class) as if they were part of their own language. In most other languages, the way to interface with different languages is by using the C ABI, which is somewhat limiting in an OOP world. In this sense, java is the new C. Also, the jvm provides garbage collection and reflection and such nice things.

Answer 3

I've put together some of the answers..

While I haven't tested them.. I see nice examples that make sense to me, from within the answers, of

Bruno provided an example in C

#include <win32.h> (An OS specific line and code would have to be rewritten for a different OS) anything that's limited to using calls in stdio.h and a few others (are portable)

Gary, spoke of a case with int. That in C, "an int is 32-bit on a 32-bit box. 64-bits on a 64-bit box" "the portable way is to use int32_t" and a point about C and assembly language.. I have asked around and found that if you go over the limit, it cycles back to 0. So, that'd be a case of code having a different effect on a different system and compiling, but perhaps not working as intended, and it having to be rewritten.

Thorbjørn provided a link to examples of assembly language on different CPUs . Win32 ASM for 32-bit CPUs and Win64 for 64-bit. It has a hello world example in each, and says that it's not easy to convert them, since "In Win32, all the parameters are passed via the stack, however in Win64 they are passed via the registers." He said it uses different instructions.. I guess thouh perhaps it's more than that, in the sense that if it's a different assembly language.. and assembly language is an obvious case of non portability.. hence I didn't mention it in the question, but it's good to see the examples at that link. And it's good knowledge to have. Good to see some contemporary assembly languages not obscure machines..

Answer 4

Guess you are talking of porting issues. Indeed JVM is what is spoken of in popular literature, that Java eliminates the need for code porting is a shade more subtle.

You don't have to look too far. A small industry of Windows to UNIX code porting developers [and vice versa] exist for this precise reason. Want examples? How about things like those near, far pointers in C? Or using __declspec(dllexport) to create a Windows specific dll while gcc will have none of this and you need -shared option?

One of the most difficult scenario was with doing C++ based GUI in particular before QT came into existence. Loads of GUI is still done on .NET, legacy code is on MFC and for Linux/UNIX a lot of legacy code is in XWindows. Java is a godsend in such cases -- most stuff will work without re-inventing the wheel across platforms.

Answer 5

... where everybody has a compiler specific for their platform. So the advantage isn't explained by that.

Porting code written in for example C or C++ is almost always much more involved than simply recompiling the code. It's certainly not something that an average, non-developer computer user can do easily. Code written in compiled languages is very often written against the API of a specific operating system (the Win32 API, for example) and so it cannot be compiled on other operating systems easily.

Java bytecode runs on any platform where there is a Java runtime environment available. The code doesn't need to be recompiled. Ofcourse you can write operating-system specific code in Java, but Java's standard library, and the many free libraries available on the web, provide a very rich cross-platform environment.

Besides portability, running on a virtual machine has other advantages. Java uses a JIT compiler to compile Java bytecode to native machine code at runtime. The JIT compiler can do sophisticated optimizations for the specific CPU that the program is running on and it can use profiling information that wouldn't be available to an ahead-of-time compiler - in principle, a JIT compiler can therefore produce more optimal code than a "normal" compiler.

Besides the Java VM, there are other virtual machines. For example, Microsoft .NET contains the CLR (Common Language Runtime) and there's also LLVM, which has front-ends for many different languages including C and C++ (and which is supposed to bring the advantages of JIT compilation also to C and C++).

Answer 6

Of course, it looks similar to the current situation, where everybody has a compiler specific for their platform.

The thing you need to understand is that even if there is a compiler specific for each platform, the languages are slightly different (unless it is the exact same compiler, which is rare for others than the gcc compiler), and that the platform the programs see are vastly different. "Oh, we have 64-bit integers here, and you need to use X11 to do graphics etc etc etc". You need to handle these things in code, and just the fact that there exist a pretty big GNU project just for handling the configuration of specifying these differences to programs (automake) should indicate that this is not a trivial matter.

The platform provided by a JVM is much more rigidly specified, and your programs behave the same on all of them. Integers overflowing? Oh, that means do this, and ignore that. etc. This is so well done that it is expected that things work the same on all JVM's, and that failures are not due to platform differences between development and deployment machines. You always look first for some external reason and only in the rarest cases you find a bug in the JVM. A very well-engineered piece of work.