Dynamically load third-party jar files in executable jar files

I. Preface

In commercial development, development classes are often packaged into jar packages for release. many third-party jar packages provide function sets, so these function packages are often used. the following scenarios are frequently encountered by many Java developers: in the Development and debugging phase, the self-compiled class works normally by setting the third-party jar package path in classpath. after the development is complete, during the deployment, compress the developed class into an executable jar package. forname (string classname) or classloader. getsystemclassloader (). loadclass (string classname) to dynamically load the class that exists in a third-party jar package will throw an exception "classnotfoundexception.

This problem occurs when the jar package is run through Jar-Jar yourself. jar and the class in the jar is dynamically loaded into a third-party class through class. forname (string classname.

Common applications, such as dynamically loading JDBC driver from different vendors based on user selection and configuration.

Ii. Background Knowledge

Since JDK 1.2, JVM has adopted the delegate (delegate) mode to load the class. The reason for this design can refer to the http://java.sun.com/docs/books/tutorial/ext/basics/load.html

To sum up, it provides a customizable security mechanism for the Application Layer Based on the JVM sandbox installation model.

Iii. Sequence of finding classes in Java Virtual Machine (JVM)

3.1 Bootstrap classes

The core class of the Java platform, such as Java. lang. string. and RT. jar and other important core-level classes. this is loaded by JVM Bootstrap class loader. usually placed in the {java_home}/JRE/lib directory

3.2 extension classes

Java-based extension mechanism is used to expand Java core functional modules. For example, Java serial communication module comm. jar is generally placed in the {java_home}/JRE/lib/EXT directory.

3.3 user classes

Java packages developed by developers or other third parties. use the-classpath or-CP command line, or set the classpath environment variable to reference. by placing the JVM in {java_home}/lib/tools. jar to find and call user-level class. the commonly used javac also calls tools. jar to find the JAVA Source Code Compiled by the user. this leads to the order or priority of the user class path search.

3.3.1 default value: Call the current path (.) of Java or javaw, which is the current directory of the developed class.

3.3.2 path set for the classpath environment variable. If classpath is set, the value of classpath overwrites the default value.

3.3.3 execute the value of the Java command line-classpath or-CP. If one of the two command line parameters is specified, its value will overwrite the value of the environment variable classpath.

3.3.4-jar option: If you use Java-jar to run an executable jar package, the current jar package will overwrite all the above values. in other words, the priority of the jar package after-jar is the highest. If the-jar option is specified, all the environment variables and the search path created by the command line will be ignored. JVM appclassloader will only use the jar package as the search range. the executable jar has many security-related descriptions, you can refer to the http://java.sun.com/docs/books/tutorial/jar/ for a comprehensive understanding.

This is why third-party jar packages cannot be referenced after applications are packaged into executable jar packages.

4. Solutions.

First, let's briefly summarize the architecture described above to facilitate understanding,

Java defines three levels of classes: Bootstrap class, extend class, and user class.

The user class restriction rules are the most complex. jar packages that can be executed in user class, including independent security rules. therefore, the solution is based on three different Java class extension mechanisms. There are three different solutions.

4.1 Bootstrap class extension scheme

The Java command line provides a simple method for extending the bootstrap class.

-Xbootclasspath: the basic core Java class search path. This path is not commonly used. Otherwise, you must re-write all Java core classes.

-Xbootclasspath/A: The suffix is behind the core Class search path. It is commonly used.

-Xbootclasspath/P: the prefix is before the core Class search path. It is not commonly used to avoid unnecessary conflicts.

Syntax:

Java-xbootclasspath/A:/path/myclass/account. jar:-jar yourself. Jar (UNIX is separated)

Java-xbootclasspath:/D:/myclass/account. jar;-jar yourself. Jar (windows are separated)

4.2 extended solution of extend class

Java exten class is stored in the {java_home}/JRE/lib/EXT directory. when Java is called, the search for extended class paths is automatic. always search. in this way, the solution is simple. Copy all third-party jar packages to the ext directory.

4.3 user class extension scheme

When you use-jar to execute an executable jar package, JVM sets the directory where the jar package is located to the codebase directory where all class searches start. therefore, if other third-party jar packages are used, a more acceptable configuration scheme is to use the manifest extension mechanism of the jar package. the procedure is as follows:

1. Copy the required third-party jar package to the directory or a subdirectory where the executable jar is located.

For example, if the jar package is in D:/CRM/luncher. jar, you can copy all the jar packages to the D:/CRM directory or the D:/CRM/lib directory.

2. Modify the manifest File

Add the following lines to the manifest. MF file:

Class-path: classes12.jar lib/class12.jar

Class-path is the keyword of the executable jar package running dependency. For details, refer to the http://java.sun.com/docs/books/tutorial/ext/index.html

In addition, writing your own classloader to dynamically load the class is more complex and advanced technology. I will not repeat it here. If you are interested, please Google Custom classloader.

4.4 recommended solution 4.1, excellent scalability.

V. Summary

The security mechanism of Java varies with different JDK versions and affects many core classes, such as thread. Therefore, many large commercial software require strict JDK versions. this is partly because of this. this also requires that you describe the JDK version for development and testing regardless of the size of your own applications.

This article is based on JDK 1.4.1 _ 03 for Windows.