The computer can only read machine code 0101… Programming languages -> executable machine code needs to be preprocessed -> compiled -> assembled -> linked -> machine code process. A diagram of a language processing system is shown below:
A compiler translates a source language program into an equivalent program written in the target language at once. Another common type of language processor exists, the interpreter: it is a source language program that executes statement by statement. Target language programs produced by a compiler are usually faster than an interpreter, but the interpreter is usually better at error diagnosis.
The Java language processor combines the process of compilation and interpretation. A.Java source program is first compiled as a. Class bytecode file, which is loaded into the virtual machine, which translates the bytecode into machine code.
The advantage of virtual machines is that once a program has been converted to Java bytecode, it can run in virtual machine implementations on different platforms. Implement write once, run anywhere. Another benefit is that it brings in a hosting environment. This managed environment takes care of tedious and error-prone parts of our code, such as automatic memory management and garbage collection.
In Hotspot, virtual machines translate bytecode in two ways:
1. Interpretive execution is the translation of bytecode into machine code and execution.
2. Just-in-time compilation Compiles all the bytecodes contained in a method into machine code before execution.
The former has the advantage of not having to wait to compile, while the latter has the advantage of actually running faster. HotSpot defaults to hybrid mode, combining the benefits of both explain execution and just-in-time compilation. It interprets the execution of bytecode, and then compiles the hot code in it, on a methods-by-methods basis, in real time.
Just-in-time compilation is based on the assumption that the program complies with the 80-20 rule, which means that 20 percent of the code takes up 80 percent of the computing resources.
All right, we’re done with the X.
Auntie know all the compilation knowledge in the above. (FLYING ╥╯ ╥ ╰╥ C)
As mentioned, let’s look at what we can do to get a Java project up and running.
What we can do is very simple, certainly not write virtual machines. We just need to:
1. Run the command javac command. The Java file becomes a. Class file. 2. Run command Java to make the. Class file run.
Execute command 🙂
How Java programs are run
Java programs can run. Class files or executable Jar files through Java commands. Let’s look at the first way: Start with Hello World.
Run the.class file
Step1: write a Java file
Step2: run command javac
Change a.Java file to a. Class file
Tip: The full path name of a class file is the package name directory + class name.
Step3: run command Java
Run the.class file
Amazingly, we didn’t use an IDE to make Java programs run 🙂
Don’t t spray old aunt, there is no such a simple Java project. We work with Jar files… Jar file run!!
Run the executable Jar file
A Jar file is a file format based on the ZIP file format that aggregates a large number of Java class files, associated metadata, and resource files (text, images, and so on) into a Jar file, along with an optional meta-INF folder. Files or folders in this folder are used to package and extend configuration information, including security, versions, extensions, and services. For example, the manifest.mf file defines the relevant data information for the extension and packaging. A Jar file is usually used as a third-party class library in a project and is part of the project build.
There are roughly two steps to generating a Jar file:
1. Compile the source file as a. Class file
2. Use the command jar command to create. Class files, resource files, and so on into a jar file in file format.
Let’s take an SbDemo project as an example to see how Jar files are packaged and run. The project directory structure is as follows:
Test2. Java calls the test1. Java method,
We need to compile test1.java into a test1.jar file, and then compile test2.java into an executable test2.jar file from test1.jar.
The difference between executable and non-executable Jar files is whether the entry to the main method is specified in the Jar file, as we’ll see later.
Step1: Test1. Java compilation 
Step2: compile classes/com/ test1. class file into test1. jar package
The java-related commands for jar packages areThe jar commandTo generate a JAR package we need to defineManifest-file information file, it can define the classpath class search path for the generated JAR package, the entry class for the JAR package, and so on. Can be understood asMetadata configuration information related to Jar packages.Step2.1 write the information fileHere we useResources/manifest – test1. The text fileAs an information file
Step2.2 run the package command
Since the com.Test1 class is referenced in test2. Java, we need to specify the Classpath path at compile time. Classpath: As the name suggests, is the path location of the classes that the class to be compiled depends on. We can specify this with the javac -cp argument. The priority values for the compile-time classpath are as follows:
- If no clasSPath parameter is passed in, the value of the environment variable CLASspath is used. (Do not know how to view and set environment variables? To read auntie’s last article 🙂
- If the environment variable CLASSPATH is not found, the current folder from which the command was executed (.) is used. .
- If the javac command line passes
-classpath or -cpParameter specifies the classpath value, which has the highest priority.
Here we use -cp to specify where test1.jar is located
Step4. Compile test2. class and its dependent test1. jar into an executable jar package Step4.1 write the information fileAt this point we specify this information using the information file resources/manifest-test2.text
Step4.2 run the Jar package generation command 
Step5. Run our executable Jar 
Of course, actual projects can’t be compiled and packaged. Build tools like Maven/Gradle help us manage Jar dependencies between code, build, deploy… We probably host Maven’s build deployment commands most of the time by clicking on the IDE.
Maven, for example, first defines a project structure that we write code to introduce the Jar dependencies required by each module. Maven can then manage the clean, build, package, and deploy phases of the project through its own lifecycle. There are Maven plug-ins for each phase that perform the corresponding goals. The IDE also integrates Maven, allowing us to run projects with a click of a button.
But when a project is not built according to the canonical build tool structure, or the project fails to run successfully, understanding the actual Java compilation process can be helpful in understanding and resolving such problems.
Well, for lack of space, I won’t talk about the pits Maven has lain in over the years. Would you like to see anything? Attention, look, forward three consecutive response under >-<
Resources: [1]. “compiler principle” sequence (゚ ´ omega ` ゚) ゚ [2]. Time.geekbang.org/column/arti…