Computer high-level language according to the execution of programs can be divided into two types of compilation and interpretation.
We can use HelloWorld to understand the specific meanings of these acronyms:
1 Public class HelloWorld {2 Public Static void Main (string[] args) {3 System.out.println ("HelloWorld"); 4 }5 }
Helloword
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? (?)
1 Java program running mechanism