Four ways to run a jar application to reference 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.jar

Unix java-xbootclasspath/a: Some.jar:some2.jar:-jar Test.jar

Win32 system each jar is separated by semicolons, and the UNIX system is separated by colons

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.

Different classes in the Java application environment are loaded by different classloader.
The default ClassLoader in a JVM are bootstrap ClassLoader, Extension ClassLoader, App ClassLoader, respectively:

Bootstrap ClassLoader is responsible for loading Java base classes, mainly Rt.jar, Resources.jar, Charsets.jar, and class in the%jre_home/lib/directory extension ClassLoader is responsible for loading the Java extension classes, primarily the jar and Classapp in the%jre_home/lib/ext directory, which is responsible for loading all classes in the classpath of the current Java application.

Where Bootstrap ClassLoader is the JVM level, written by C + +, Extension ClassLoader, App ClassLoader are all Java classes, inherited from URLClassLoader superclass.
Bootstrap ClassLoader is initiated by the JVM, then initializes sun.misc.Launcher, sun.misc.Launcher initializes extension ClassLoader, App ClassLoader.

Bootstrap ClassLoader, Extension ClassLoader, App ClassLoader The relationship between the following:

Bootstrap ClassLoader is Extension classloader parent,extension ClassLoader is the parent of app ClassLoader.

But this is not an inheritance relationship, just a semantic definition, basically, every ClassLoader implementation, there is a parent ClassLoader.

The parent of the current ClassLoader can be obtained through the ClassLoader GetParent method. Bootstrap ClassLoader is special because it is not a Java class, so the GetParent method of extension ClassLoader returns NULL.

After understanding the principles and processes of classloader, we can try custom ClassLoader.

About Custom ClassLoader:

Due to some special requirements, we may need to customize the load behavior of ClassLoader, then we need to customize the ClassLoader.

The custom ClassLoader needs to inherit the ClassLoader abstract class, overriding the Findclass method, which defines how ClassLoader finds the class.

The main methods that can be extended are:

Findclass define how to find class

DefineClass loading class file bytecode as class in the JVM

FindResource define how resources are found

If we have trouble, we can use or inherit the existing ClassLoader implementations, such as

• java.net.urlclassloader

• java.security.secureclassloader

• java.rmi.server.rmiclassloader

• sun.applet.appletclassloader

Extension ClassLoader and App ClassLoader are all subcategories of java.net.URLClassLoader.

This is the construction method of URLClassLoader:

Public URLClassLoader (url[] URLs, ClassLoader parent)

Public URLClassLoader (url[] URLs)

The URLs parameter is an array of classpath URLs that need to be loaded, and you can specify the parent ClassLoader, which defaults to the ClassLoader of the currently calling class as the parent.

ClassLoader ClassLoader = new URLClassLoader (URLs);  Thread.CurrentThread (). Setcontextclassloader (ClassLoader);    Class Clazz=classloader.loadclass ("Com.company.MyClass"),//The class is loaded using the LoadClass method, which is below the classpath specified in the URLs parameter. Method Taskmethod = Clazz.getmethod ("Dotask", String.class, String.class);//Then we can do something with reflection taskmethod.invoke ( Clazz.newinstance (), "Hello", "World");

Because the ClassLoader load class uses the overall responsibility for the delegation mechanism. The so-called overall responsibility, that is, when a classloader loading a class, the class depends on the and reference of all classes are also loaded by this classloader, unless explicitly using another classloader loading.

So, when our custom ClassLoader load succeeds com.company.MyClass, all the dependent classes in MyClass are loaded by this classloader.

This article is from the "Wind Trace _ Snow Tiger" blog, please be sure to keep this source http://snowtiger.blog.51cto.com/12931578/1960155

Four ways to run a jar application to reference other JAR packages