Java Operating mechanism details

JVM (Java Virtual Machine) a specification for computing devices that can be implemented in different ways (software or hardware). The instruction set for compiling the virtual machine is very similar to the instruction set of the compiled microprocessor. A Java Virtual machine consists of a set of bytecode instructions, a set of registers, a stack, a garbage-collected heap, and a storage method domain.

A Java Virtual machine (JVM) is an imaginary computer that can run Java code. As long as the interpreter is ported to a specific computer based on the JVM specification description, any compiled Java code can be guaranteed to run on that system.

1. Why use a Java virtual machine

A very important feature of the Java language is its independence from the platform. The use of Java virtual machines is the key to achieving this feature. General high-level languages if you want to run on a different platform, you need to compile at least a different target code. When the Java language virtual machine is introduced, the Java language does not need to be recompiled when it runs on different platforms. The Java language usage mode Java Virtual machine masks information related to specific platforms, allowing the Java language compiler to generate only the target code (bytecode) that runs on a Java virtual machine, which can be run unmodified on multiple platforms. When a Java virtual machine executes a bytecode, it interprets the bytecode as a machine instruction execution on a specific platform.

Java operating mechanism

Java programs must be written , compiled , and run in three steps.

Writing refers to the input of program code in the Java Development environment, resulting in a Java source file with a suffix called. java.

Compiling is the process of using the Java compiler to troubleshoot source files, and compiling a bytecode file with a. class suffix, which does not end up producing executables like the C language.

Run refers to the use of the Java interpreter to translate bytecode files into machine code, executing and displaying the results. This procedure is shown in 1.1.

A bytecode file is an intermediate code that is independent of any specific machine environment and operating system environment and is a binary file that is a target code file generated by the Java compiler after the Java source file is compiled. Neither the programmer nor the computer can read the bytecode file directly, it must be interpreted by a dedicated Java interpreter, so Java is a language that runs on a compilation basis.

The Java interpreter is responsible for translating bytecode files into machine code under specific hardware environments and operating system platforms for execution. Therefore, the Java program cannot run directly on the existing operating system platform, it must run on the software platform called the Java Virtual machine.

A Java Virtual machine (JVM) is a software environment that runs Java programs, and the Java interpreter is part of a Java virtual machine. When running a Java program, the JVM is first started and then it is responsible for interpreting the bytecode that executes Java, and the Java bytecode can only run on top of the JVM. This allows the JVM to separate Java bytecode programs from specific hardware platforms and operating system environments, as long as the Jvm,java program for a specific platform is installed on different computers, regardless of the current specific hardware platform and operating system environment, or Consider the platform on which the bytecode files are generated. The JVM hides the specific differences between the different hardware and software platforms, thus enabling a true binary code-level cross-platform migration. The JVM is a Java platform-Agnostic Foundation, and the cross-platform nature of Java is implemented by running Java programs in the JVM. This operating mechanism of Java can be illustrated by figure 1.2.

This "write Once,run anywhere" approach in the Java language effectively solves the problem that most advanced programming languages need to compile different machine code for different systems, that is, the heterogeneous problem of the hardware environment and the operating platform. Significantly reduces the cost of program development, maintenance, and management.

It is important to note that Java programs can achieve cross-platform features through the JVM, but the JVM is not cross-platform. That is, the JVM on top of the different operating systems is different, the JVM above the Windows platform is not available on Linux, and vice versa.

Example:
We can use HelloWorld to understand the specific meanings of these acronyms:

public class HelloWorld {public static void main (string[] args) {System.out.println ("HelloWorld");}}

After compiling, we got the Helloworld.class ("Your program's class files" in the figure)
Inside HelloWorld, we call the static member object of the Java.lang.System class in the Java API out, the static method of out: public static void println (string string);

Then we let the virtual machine execute the HelloWorld.
1. Virtual opportunity to find Helloworld.class in Classpath.
2. The interpreter (interpret) in the virtual machine interprets the helloworld.class as a byte code.
3. Send the interpreted bytecode to execution engin for execution.
4. Execution Engin calls native method (the platform-related bytecode) to print out the specified string in the specified part of the stdout (display) of the host system.
5. In this way, we will see the words "HelloWorld".

With this process, we have a good understanding of these terms:
A. Jdk:java develop Kit (Java API pack)
B. Sdk:software develop kit, formerly known as the JDK Java Software Develop kit, later, after the release of version 1.2, it was called the JDK, saving time and effort, save costs.
C. JRE. Java Runtime Environment Our HelloWorld must be in the JRE (Java runtime, Java Runtime, also known as Java Platform) in order to run. So, obviously, the JRE is actually the JDK + JVM.

D. JVM Java Virtual machine. Simply put, the class file is converted into bytecode and then sent to Excution engin for execution. And why is it called a virtual machine instead of a real machine? Because the JVM itself is not operational, and can not let the display "HelloWorld", it can only call the host system API, such as in the W32 will be the C + + API, to let the CPU do arithmetic operations, to invoke C + + Inside the API to control the display display string. And these APIs are not inside the JDK, we usually do not see, so we call it native API (also said private xx).

E. Explanation of platform-independent. Some people will say, in the Linux call native API and W32 inside call API certainly not the same? So why is it that Java is platform-agnostic?
In fact, you do not see java.sun.com inside and there are jdk-for-w32 and jdk-for-linux download it? Didn't you just say it? Native API, native API, is our usual invisible API! Call native These tedious jobs have been made by the JDK. So when we call only to know the JDK (Java API) inside the java.io.* can provide disk access function, java.awt.* can draw a box to draw a circle on the line. As to how the JDK is called, is it more rounded on the Linxu? Still more round on the W32, (x) This is the JDK personal thing. (In theory, it is the same round, of course, it is related to whether the display is flat): D)

At the same time, there is another topic. How to write platform-independent Java programs. One of the key points is to call and invoke only the APIs in the JDK, rather than calling the native API privately. The reason is very simple ah, jdk-for-linux and jdk-for-w32 surface are the same, so I call the JDK in the W32 Java program, in Linux will also be the same way of writing Ah, so it can be transplanted to the transplant is no problem. (b) But if I invoke a graphical display of the native API in W32, who can guarantee the same name, the same parameters, the same return value, the same function native API for me when I transplant to Linux? (?)

Java operating mechanism verbose