Four ways to run a JAR application referencing other jar packages (Java command)

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

The specific method is to modify the Manifest.mf file in the Meta-inf of the jar package.

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

We just 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 this jar.

But our project needs to refer to other third party jar packages, and in eclipse we refer to this package called Some.jar in the form of a project jar package, which was placed in the Lib subdirectory of the project, and the last project was packaged with the Some.jar, but with Java- The jar was unable to find the class exception when executing this test.jar because the jar reference does not have a jar package that is placed inside itself.

So what to do.

The way it is added to the classpath at run time is not OK. 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 using Classpath is loaded by Appclassloader, and after the Java command adds the-jar parameter, Appclassloader only focus on the class in the Test.jar range, classpath parameters fail.

So how do you refer to the other jar packs?

method One, use bootstrap ClassLoader to load these classes.

We can use the following parameters at run time:

-xbootclasspath: Completely replaces the system Java classpath. It's best not to.
-XBOOTCLASSPATH/A: Load after system class is loaded. This is generally used.
-XBOOTCLASSPATH/P: Loading before system class loading, attention to use, and system class conflict is not good.  Win32 java-xbootclasspath/a: SOME.JAR;SOME2.JAR; -jar Test.jar Unix java-xbootclasspath/a: Some.jar:some2.jar:-jar test.jar Win32 System each jar is separated by semicolons, separated by colons under the UNIX system. (Windows uses a bat script, Unix uses the Sh script command)

method Two, use extension classloader to load

You can throw the jar you need to load under%jre_home%/lib/ext, and the jar pack in this directory will be loaded by extension ClassLoader after the bootstrap ClassLoader is 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, Test.jar the Some.jar package to be referenced here.

Then the test runs and everything works.

If you have 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 index.list files, the Class-path configuration may be invalidated. INDEX. The list is the index file that is generated when the jar packaging tool is packaged, and the deletion has no effect on the operation.

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 http://longdick.iteye.com/blog/442213.

Summary:

All of the above four methods can be used, especially when the program is running in a very simple environment. However, if you're running in a multitasking, multiple-application environment, it's best to be independent of each application, and the first and second scenarios are likely to have an impact on other applications, so it's best to choose the third and fourth species.

Go to: http://longdick.iteye.com/blog/332580