How the Java command executes the jar package

As you know, a Java application project can be packaged into a jar, and of course you have to specify a main class that has the main function as the program entry for your jar package.

The specific method is to modify the MANIFEST.MF file under directory Meta-inf in the jar package.

For example, there is a jar package called Test.jar, which has a main class:test.someClassName with the main function.

We just need to add the following sentence in the MANIFEST.MF:

Main-class:test.someclassname

Then we can enter Java-jar Test.jar in the console to run the jar.

However, we need to refer to other third-party jar packages in Eclipse, which is a package called Some.jar in the form of project jar packages, which was placed in the project's Lib subdirectory, and the last project was packaged with this some.jar, but with Java- The jar does not find a class exception when executing this test.jar because the jar does not reference the jar package that is placed inside itself.

So what?

How about adding classpath to the runtime? is to add the Classpath parameter while running the jar:

Java-classpath Some.jar-jar Test.jar

This is not possible because the jar specified with Classpath is loaded by Appclassloader, and after the Java command adds the-jar parameter, The Appclassloader only focuses on the class within the Test.jar range, and the Classpath parameter fails.

So how do you refer to other jar packages?

Method One, use bootstrap ClassLoader to load these classes

We can use the following parameters at run time:

-xbootclasspath: Completely replace the system Java classpath. Better not.
-XBOOTCLASSPATH/A: Loaded after the system class is loaded. usually with this.
-XBOOTCLASSPATH/P: Loading before system class load, attention to use, and system class conflict is not good.

Win32 java-xbootclasspath/a: SOME.JAR;SOME2.JAR; -jar Test.jarunix java-xbootclasspath/a: Some.jar:some2.jar:-jar test.jarwin32 system each jar is separated by a semicolon, and the UNIX system is separated by a colon

Method Two, use extension classloader to load

You can throw the jar you need to load under%jre_home%/lib/ext, and the jar package in this directory will be loaded by extension ClassLoader after Bootstrap ClassLoader has finished working. Very convenient, very worry. :)

Method Three, or use Appclassloader to load, but do not need classpath parameters

We add the following code to the MANIFEST.MF:

Class-path:lib/some.jar

Lib is a subdirectory of the same directory as Test.jar, and the Some.jar package Test.jar to reference is here.

Then test run, everything is OK!

If there are multiple jar packages that need to be referenced:

Class-path:lib/some.jar Lib/some2.jar

Each individual jar can be separated by a space. Note Use relative paths.

Another: If the Meta-inf contains the Index.list file, it may invalidate the Class-path configuration. INDEX. List is the index file that is generated when the jar packaging tool is packaged, and the deletion has no effect on the run.

Method Four, custom ClassLoader to load

This approach is the ultimate solution, and basically those well-known Java applications are so dry, such as Tomcat, JBoss, and so on.

This approach is a bit complicated and requires a special discussion. The principle of ClassLoader and the custom ClassLoader can refer to this article http://cuixiaodong214.blog.163.com/blog/static/951639820099135859761

Summarize:

The above four methods can be used, especially when the program runs in a very simple environment. However, if you are running in a multi-tasking, multi-application environment, it is best to be independent of each application, and the first and second scenarios can have an impact on other applications, so it is best to choose the third and fourth.

Original: https://www.cnblogs.com/zpbolgs/p/7267384.html

How the Java command executes the jar package