What is meant by "implementation of JVM"?

[Mansukhdeep Thind]

Every now and then I come across a statement that says "..... which is dependent on the implementation of the JVM". What exactly is meant by implementation of the JVM? Who creates these implementations? Guys at Sun/Oracle? Can I make my own implementation of JVM? Is yes, how?

[Campbell Ritchie]

What that means is that the actual internal details can vary from implementation to implementation. The best‑known implementation comes from Sun/Oracle, but there are others from IBM, OpenJDK etc. Yes, you can make your own implementation. Start by understanding the whole Java Language Specification

[Jesper de Jong]

Oracle determines the specification of the JVM, and then Oracle and other vendors make different implementations of that specification for different operating systems.

For example, Oracle makes a JVM for Windows, and one for Linux, and one for Solaris, and other vendors make JVMs for their own operating systems.

Yes, you could implement your own JVM, but that would ofcourse not be a simple project, and probably far too big and too complex for a single person. And if you're officially allowed to call it a Java Virtual Machine depends on Oracle, you'll need a license from Oracle and it will need to pass Oracle's compatibility tests before you can officially call it Java.

Apache tried to make a fully open source, free software implementation of the JVM called Apache Harmony but they gave up, because formerly Sun and now Oracle did not want to cooperate with the licensing.

[Campbell Ritchie]

And sorry for spelling best‑known wrongly earlier. I have corrected it.

[Mansukhdeep Thind]

Where can I see the implementation that is written by guys at Oracle? Is it available? Are they simply java sources or mixture of Java and native(C) sources?

[Jesper de Jong]

See http://openjdk.java.net/

[Mansukhdeep Thind]

OK. So these are some sort of op-codes / mnemonic codes which are used to instruct the underlying platform to perform the specific task like class format verification, semantics, loading, calculations etc. Correct?

[Jeff Verdegan]

Mansukhdeep Thind wrote:OK. So these are some sort of op-codes / mnemonic codes which are used to instruct the underlying platform to perform the specific task

Yes. Just like every single program that runs on every single computer ever made.

Some part of the JVM is native code for the underlying processor. It has to be. It could have been written in assembly, or machine language, or by flipping switches on a panel, but mostly it's written in C or C++. That C++ is compiled to native machine language for that platform. Other parts of the JVM can be written in Java. Just like any other Java code, that Java code is turned into bytecode (machine language for the JVM), and then interpreted or compiled (by other parts of the JVM) into native machine language for the underlying platform.

[Mansukhdeep Thind]

Thank you..

[Jesper de Jong]

Mansukhdeep Thind wrote:OK. So these are some sort of op-codes / mnemonic codes which are used to instruct the underlying platform to perform the specific task like class format verification, semantics, loading, calculations etc. Correct?

That's why it's called the Java Virtual Machine. Java is normally compiled to bytecode for the JVM. Bytecode consists of machine language instructions (opcodes with operands) for a virtual (as opposed to a real, physical CPU) machine.

The JVM runs the bytecode, just like a CPU does in hardware: it looks at each instruction and then executes it on the underlying operating system and CPU. To make things run faster, Oracle's JVM includes a JIT (Just In Time) compiler, which translates Java bytecode to native machine instructions, which are then executed. Programs run a lot faster because the JIT has to convert the bytecode to native code only once, and the native code can then be run many times.

Oracle's JVM is written in C++.

There are a number of advantages to having a virtual machine instead of compiling source code directly to native machine instructions. It means that your compiled code is CPU-independent, so you can easily run it on different kinds of CPUs without needing to recompile it. Also, the JVM can do certain optimizations for the specific CPU that the program is running on that would be hard to do if you would compile the code to native code ahead of time.

[Mansukhdeep Thind]

So the byte-code is platform independent. But then there are different jdk installables for different platforms such as for Windows/Linux/Solaris etc. That means the JVM implementation differs according to the underlying platform's architecture. But a byte-code that produces a certain output on a Windows machine will produce the same output on a Sun / Linux / IBM machine. And it does not need to be recompiled again on different machines. I can compile it on Windows and run it on Linux and vice-versa. Is that right?

[fred rosenberger]

that is the basic idea, yes.

Note that is is possible to write code that won't run on different systems, like if you make a system call.

[Mansukhdeep Thind]

What's a system call? As in some commands that are specific to the platform kernels?

[Joanne Neal]

Mansukhdeep Thind wrote:But then there are different jdk installables for different platforms such as for Windows/Linux/Solaris etc.

There are different JDKs for each platform, but these are for developing applications. To run a Java application you only need a JRE (which is a JVM plus associated libraries and resources), but again there is a different JRE for each platform.

[Mansukhdeep Thind]

Learned something new today. Thank you to all of you. Surprising that I asked the most fundamental question after reading through most of Java.

[Jeff Verdegan]

Mansukhdeep Thind wrote:What's a system call? As in some commands that are specific to the platform kernels?

I'm not sure what Fred means by "system call," but there are some things that may work on one platform but not the other, or that may "work", but behave in a way you didn't want. This is usually the result of the programmer explicitly writing platform-dependent code. Some examples:

Making assumptions about the file system, such as that it has a single root /, or multiple roots C:\, D:\, etc.; rather than relying on the I/O tools in the core API for that stuff.

Hardcoding a command to Runtime.exec() or ProcessBuilder.

Although I don't use Swing, I understand that there are a couple ways that you can write UI code that won't work cross-platform if you're careless.

Assuming that the resolution you see for the System.currentTimeMillis() or System.nanoTime() on one platform will be the same on other platforms. (This also applies across different JVM implementations or different hardwarde/OS versions of the same platform.)

Assuming thread scheduling you see on one platform will work the same way on another platform. (This also applies across different JVM implementations or different hardwarde/OS versions of the same platform, or from one execution of your code to the next on the exact same host.)

[fred rosenberger]

you can, using java, explicitly call a command on the underlying OS. So, if i wanted to rename a file, I could call "mv fileA.txt fileB.txt" on my unix machine. This would work fine (although there are some caveats to this), until I moved my class file to a windows box. There, it would not work at all, since Windows doesn't have "mv", but "rename"

[Jeff Verdegan]

fred rosenberger wrote:you can, using java, explicitly call a command on the underlying OS. So, if i wanted to rename a file, I could call "mv fileA.txt fileB.txt" on my unix machine. This would work fine (although there are some caveats to this), until I moved my class file to a windows box. There, it would not work at all, since Windows doesn't have "mv", but "rename"

Ah, ok.

@OP: That's the Runtime.exec()/ProcessBuilder bullet point in my post.

[Mansukhdeep Thind]

Understood.