Java Program Execution principle

Transferred from: http://blog.csdn.net/walkingmanc/article/details/6369487
Java applications can be packaged in a jar format, and the jar format is a very common compression format, just like the zip format, except that it adds a meta-inf/manifest to the directory structure of the compressed file. MF meta-file.

We know that the compiled bytecode class file can be placed directly into the Java Virtual machine to interpret the execution (JIT mode), we can use the JVM by invoking the "Path of the Java class file" at the command line (java.exe/ Javaw.exe) to explain the execution of these bytecode files.

We know that Java source code (. java files) is compiled by the Java compiler Javac and will get Java bytecode in the intermediate language file. That is, the class files (. class files) that we usually call, which are stored in the package structure of the Java source file, the role of the jar command is to package these byte-code class files according to the package directory structure, form a jar package, and add a meta-inf/ MANIFEST. MF meta-file. The packaged jar file does contain a byte-code class file that is stored in the package directory structure, but at this point you will be prompted to specify a main class if you are on the command line: Jar-jar A.jar, because Although the jar package contains a byte-code class file that is stored in the package directory structure, it does not know the location of the main class (the class that contains the public static void Main (string[]) Portal method), so you need to specify the main class manually before you can begin execution.

Of course, only when packaging the jar file, the main class information is included in the later, then: Jar-jar A.jar, there is no need to manually indicate which class is the main class. Do the following:

Create a new. mf file with the name arbitrary, for example: MANIFEST.MF, which specifies which class is the main class, that is: Write one line: Main-class:test. Test. Then, package: Jar CVFM test.jar MANIFEST.MF test; So the package Test.jar inside contains the information of which class the main class is. In this case, execute directly on the command line: Jar-jar Test.jar can run the application, in which cases the JVM will go to the class file's package to find out how the entry function goes into execution.

When we publish a Java application, it is obviously inconvenient to publish the class folder that is stored in the package structure, which is usually packaged as a jar file for publishing. Just as we did when we deployed the Java application to the Tomcat Web server, although it was possible to put the class folder directly in the package structure, it was usually packaged in the format of a jar package, because there would be fewer files to manage the deployment.

Write the path of the Java-jar jar file for the command line into a. bat file or a shell file underneath Linux so that you can execute the Java application by executing the. bat file or Shell footstep. This means you can simply double-click the. bat file under Windows or the. sh file under Linux to run the Java application.

In general, when installing the JRE (Java Runtime Environment), the installation file maps the. jar file to Javaw.exe open, and if there is no association, you can manually associate through the folder option. When the user double-clicks the jar file under Windows, the Resource manager invokes JAVAW to run the jar file, allowing the double-click to run the jar file.

JDK related process principle analysis.

We know that there are many EXE files in the bin directory of the JDK, such as Java.exe, Javac.exe, Javadoc.exe and so on. These EXE file formats are essentially executable file formats under the Windows operating system (in DOS there is an executable but a. com suffix format, but it is not common now), they are written in C. c files are compiled and generated. For example: Java.exe corresponding source code is the java.c file. The function is called in the main entry function of JAVA.C: Createexecutionenvironment, which finds the JRE path and then loads the Jvm.dll dynamic Connection library based on the virtual machine Dynamic link library (jvm.dll) path parameter configured by the JVM.CFG configuration file, which is the load Java Virtual machines (Java Virtual machines are written in C + + and some C code), then initialize Jvm.dll (all DLLs are written in the local language), hook up to the JNIENV (JNI call interface) instance, and finally call the JNIEnv instance to mount and process the class.
As we can see from the above analysis, EXE files under the Windows operating system are mostly compiled with code written in the Windows native language, which are used to accomplish certain functions, such as Java.exe, which can be used to find and load Jvm.dll, It then loads the Java Bytecode Intermediate language file. class file by calling the Jvm.dll interface and launches the Java application. or complete some other functions. EXE files may also be generated by the native language code that the EXE file is compressed with the jar package.

A more convenient way is to make the jar into an EXE. For example, Eclipse is a Java application that uses EXE to wrapper.

Wrapper rationale: Call Jvm.dll in a localized language (C or C + +, etc.) code and then load the ingress method of the main class classes in a jar package that is compressed with the Jvm.dll provided by the interface (static void Main (String args[] To launch a Java application, this shell-shaped Java application EXE file will appear as an EXE process at startup, which is more common. (The form is an EXE file that is compressed by the localization language EXE and the jar package);

You can also call java.exe/in the localized language (C or C + +, etc.) code The Javaw.exe process (the Java.exe process performs the steps of the previous method to complete the Jvm.dll load) to load the Jvm.dll, and then loads the ingress method of the main class classes in the jar package that is compressed with the Jvm.dll provided by the interface (static void Main (String args[]) to start the Java application, the shell-shaped Java application EXE file will be displayed as an EXE process and a JAVAW process when it starts. (The form is an EXE file that is compressed by the localization language EXE and JAR package, of course, you can choose not to compress the jar file and the local EXE file together);

Both are essentially loading the Java Virtual machine through local code and then loading the class master file and starting the Java application in the local code by invoking the Jvm.dll interface.

Specifically, there are a number of ways.

You can use native languages such as C to create a local code (compiled to generate an EXE file), load the JVM's dynamic library in the native code, and start the Java Virtual machine in this process through the interface of the dynamic library, that is, call JNI_CREATEJAVAVM this export function to create the Java virtual machine , get the jnienv pointer, then call Findclass to find the main Class, then call the Getstaticmethodid method to get the main method, and execute the main method. Compile the local code to get an EXE file.

Package the Java application's class directory structure as a jar file and merge with the local code EXE file: Execute the copy command at the DOS prompt:

C:/>copy Test.exe+test.jar Test.exe
In fact, the Java package file is appended to the end of the EXE file. Opens the File Properties dialog box, where you can see the Compressed Files property page.
The Old JBuilder.exe development tool compiles the generated EXE file, which is generated in the following way.
PostScript: When you use Eclipse 3.2 and Eclipse 3.3, you'll see the difference in Task Manager.
Eclipse 3.2 is the first to start the Eclipse.exe file, and then the Eclipse.exe launches the Javaw.exe file to create the virtual machine.
Eclipse 3.2 is displayed as Eclipse.exe and Javaw.exe two processes in Task Manager.
Eclipse 3.3 appears in Task Manager as a Eclipse.exe process.
As you can see from the above, Eclipse 3.2 and Eclipse 3.3 have different ways of loading virtual machines.

Eclipse 3.2 uses the method call Javaw.exe to create child processes to start, under Windows can use the CreateProcess method, this method is simpler, see the Eclipse source code specifically.

Another way to load the Java virtual machine in Eclipse 3.3 is to load the JVM's dynamic library and launch the Java Virtual machine within the process through the interface of the dynamic library. The second method that is used at the beginning of this article.

Write an EXE and call Java.exe to start a process.
This is very simple, start VC, build a Win32 Project,winmain use ShellExecute function, the main code is:

#include "stdafx.h"
#include "resource.h"

int Apientry WinMain (hinstance hinstance,
HInstance hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow)
{
ShellExecute (NULL, "open", ".//jre6//bin//javaw.exe", "-ea-dfile.encoding=gb18030-xmx600m-splash:res//splash.png- Classpath/"./lib/*/" Com.zms.laser.uis.Starter ",".//", SW_SHOWNORMAL);
return 0;
}
To give the compiled executable an icon, it is very simple, just add an icon of the resources, so that the ID of the icon can be minimized. The compiler will treat the icon with the minimum ID as the final exe.

All of the tools used to add EXE Shell to Java applications are one of the above principles.

Java Program Execution principle