1

C++ is not platform-independent because it needs to be compiled into native code and a different compiler needs to be implemented for different CPU architectures.

A C++ compiler only translates the code into machine language or native code. This native code is executed by the processor.

From what I read on the net, a Java program is initially compiled into Bytecode by the java compiler 'javac'. This bytecode is then interpreted (and executed) on a line by line basis by the Java virtual machine.

I have few queries.

1) If C++ is not platform independent because different compilers need to be designed for different CPU architectures, then doesn't JVM differ from one hardware to another as well?

2) If I wrote a C++ code and compiled and executed it on Machine 1 and Machine 2, the output produced will be the same. Similarly, if I write a Java program and execute it on two different machines, the output will still be the same. Why the extra step of bytecode generation?

3) I read somewhere that interpreters, unlike compilers, actually execute a program by emulating a virtual machine. Does it mean that JVM actually executes the bytecode and not just interprets it into native code?

Ravindra babu
  • 37,698
  • 11
  • 250
  • 211
the_stack_over_flew
  • 95
  • 8
  • 1
    Read http://stackoverflow.com/q/2748910/1110928 and http://stackoverflow.com/q/2203248/1110928. I'd contend this is a duplicate of the second question I listed. In short, you could think of the JVM as an emulated CPU, so the bytecode instruction set is the same for any hardware. – apnorton Aug 20 '15 at 18:25
  • I am still not getting why source code is not directly interpreted and executed by the JVM. – the_stack_over_flew Aug 20 '15 at 18:49
  • So you're asking "why do we compile to bytecode as an intermediate, instead of doing what, say, Python does by compiling and interpreting on-the-fly?" – apnorton Aug 20 '15 at 18:53
  • I am not familiar with Python but yes.. why compile to an intermediate language? – the_stack_over_flew Aug 20 '15 at 18:55
  • 1
    One could also phrase it like this: The Java bytecode is **highly** platform dependent. It only runs on exactly **one** platform. And this platform is... * drumrolls * .... the Java Virtual Machine (which fortunately is available for all important (non-virtual) platforms, and could be implemented on every platform). – Marco13 Aug 20 '15 at 21:28
  • 1
    The bytecode is **not** interpreted on a line by line basis. The reason it is compiled to **byte**code is that that code contains instructions composed of **bytes** not lines. And that’s easier and faster to interpret. – Holger Aug 21 '15 at 13:28

2 Answers2

2

In a sense you're right, in that you can essentially equate a C++ compiler to the combination of a Java compiler plus Java virtual machine. Neither of these two are in themselves platform independent: a Java compiler written for a Linux machine will typically not run on a Windows machine, and neither will a JVM.

However, in practice the intermediate language of Java bytecode, which is what the Java compiler produces and the virtual machine executes, makes a huge difference because it is on this level that compiled code is shipped. So if you get a Java binary, it is bytecode. Provided you have a JVM for your machine, you can run it without further ado. In contrast, a C++ binary is machine code for a particular machine; you cannot run it on any other machine than that which it was compiled for.

Now, to come to your actual questions:

  1. Indeed, JVMs differ from one hardware platform to another.
  2. The compilation step to bytecode takes care of quite a bit of processing and packaging. If you would want to do that every time you run a program, startup time would suffer. But it is certainly possible in principle, so yes, if you write a wrapper around a C++ compiler that invokes the compiler and then immediately executes the compiled program, you essentially have a virtual machine for C++ that is just as platform independent as the execution of Java bytecode.
  3. Modern JVMs are very clever and do quite a bit of further compilation during bytecode execution (called Just-In-Time or JIT-compilation). It is by no means mere bytecode interpretation.
Arend
  • 2,363
  • 1
  • 18
  • 18
2

C++ is write once, compile anywhere (at least in theory, easier said than done, but it is done)

Java is compile once, run any where (provided a JVM is installed, again there are differences between systems which cannot be hidden entirely)

If C++ is not platform independent because different compilers need to be designed for different CPU architectures, then doesn't JVM differ from one hardware to another as well?

The JVM differs but the byte code doesn't have to. The C++ can be written once but often has platform specific code. This doesn't have to be a problem, but you can expect that the code has to be tested, an custom code written for each flavour of system it is written for.

If I wrote a C++ code and compiled and executed it on Machine 1 and Machine 2, the output produced will be the same. Similarly, if I write a Java program and execute it on two different machines, the output will still be the same. Why the extra step of bytecode generation?

You only need to compile it once for Java. You can take a JAR compiled using Java 1.0 on a 32-bit windows platform running Windows 95 twenty years ago and use it immediately without the source or knowing how it way compiled, on a 64-bit ARM processor running Linux and it will use the latest optimisations and instruction set for that processor.

For C++, if you take a program written on Windows 95 twenty years ago, it probably won't compile without a lot of work and testing on a 64-bit ARM processor for Linux.

I read somewhere that interpreters, unlike compilers, actually execute a program by emulating a virtual machine. Does it mean that JVM actually executes the bytecode and not just interprets it into native code?

The JVM interpretes initially, compiles it quickly, then slower (Called C1 in the OpenJDK) and later re-otimises more aggressively (Called C2) It goes through 4 different levels of compilation and it can de-optimise code to have it re-optimised based on changing usage and even changing code.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130