The setting method of Classpath when-jar parameter runs application

When you run a packaged application with Java-jar Yourjarexe.jar, you will find out how to set the-classpath parameter application without finding the corresponding third party class, reporting classnotfound error. In fact, this is because when you run with the-jar parameter, the Java VM masks all the external classpath and only uses its own Yourjarexe.jar internal class as the search scope for the class.

* * Solution * *

One BootStrap class extension scheme

The Java command line provides a simple way to extend the bootstrap level class.
-xbootclasspath: Completely replaces the basic core of the Java class search path.
Not used, otherwise you'll have to write all Java core classes again.
-xbootclasspath/a: suffix is behind the core class search path. common use!!
-xbootclasspath/p: prefix in front of core class search path. Not commonly used, avoid
Cause unnecessary conflict.

The syntax is as follows:
(The separator is similar to the classpath parameter, UNIX uses: number, Windows uses;
Java-xbootclasspath/a:/usrhome/thirdlib.jar:-jar yourjarexe.jar

Two Extend class expansion scheme

The Java Exten class is stored in the {java_home}\jre\lib\ext directory. When Java is invoked, the search for the extended class path is automatic. Always search. In this way, the solution is simple, Copy all the Third-party jar packages that you want to use into the EXT directory.

Three User class extension scheme

When executing an executable jar package using-jar, the JVM sets the directory of the jar bundle to the CODEBASE directory, and all class searches begin in this directory. So if you use other Third-party jar packs, a more acceptable configurable scenario, is to use the manifest extension mechanism of JAR packages.
The steps are as follows:

1. You will need a third party jar package, copied in the same executable jar in the directory or a subdirectory. For example: Jar pack in/usrhome/yourjarexe.jar then you can copy all jar packages to a/usrhome directory or similar subdirectories like/usrhome/lib.

2. Modify the manifest file

Add the following line to the MANIFEST.MF file.

Class-path:classes12.jar Lib/thirdlib.jar

Class-path is the key word that the executable jar package runs on. The details can refer to http://java.sun.com/docs/books/tutorial/deployment/jar/downman.html. Note that Class-path is simply an abbreviation for the CLASSPATH environment variable of your local machine, which means that the prefix represents the search for the corresponding Third-party class/class library in all classpath directories on your jar execution machine. You are not able to load jar files that are located inside your jar bag (or on the network) by Class-path. Because theoretically, your jar release package should not contain any other Third-party libraries (and should be used to alert users to the corresponding support class libraries). If other Third-party libraries (jars, zip, class, etc.) are to be packaged directly in your own jar package because of special needs, you must load the Third-party libraries by implementing custom ClassLoader to your own intent.

The above three methods recommend the first , the expansion of the good, and the most convenient operation.
Writing your own classloader to dynamically load class is a more complex and advanced technique. Limited to space, not to repeat. Interested to know can go to Google custom ClassLoader, or refer to my other blog: let the classpath parameters away.

The Java security mechanism varies with different JDK versions and affects many core classes, such as thread, so many large business software require a very strict version of the JDK. This is partly the case. This also requires that when publishing your own written application, regardless of size, Describe the version of the JDK that was developed and tested.

The methods described in this paper are tested based on J2SDK 1.4.2_04-b05

----------------------------------------------------------------------------------------------

Attachment: Background knowledge

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

Summed up: It is based on the JVM Sandbox (sandbox) installation model to provide the application layer of customizable security mechanisms.

Java Virtual Machine (JVM) Find the Order of class

1. Bootstrap Classes

Classes that belong to the core of the Java platform, such as java.lang.String, and Rt.jar. This is loaded by the JVM Bootstrap class loader. Typically placed in {java_home}\ The Jre\lib directory

2. Extension Classes

The Java extension mechanism is used to extend the Java core functional modules. For example, Java serial communication module COMM.JAR. Generally placed in the {Java_home}\jre\lib\ext directory

3. User Classes

Java packages developed by developers or other third parties.-classpath or-CP from the command line, or by setting the CLASSPATH environment variable. JVM by placing in {java_home}\lib\ Tools.jar to find and invoke user-level classes. The common Javac is also to compile the Java source program by calling Tools.jar to find the path specified by the user. This raises the question of the order or priority level of the user class path search.

3.1 Default value: invokes the current path (.) of Java or Javawa, the current directory where the developed class exists
3.2 Classpath The path of the environment variable setting. If Classpath is set, the Classpath value overrides the default value
3.3 Executes Java command line-classpath or-CP value, if one of these two command-line arguments is drawn, its value overrides the value of the environment variable Classpath
3.4-jar option: If you run an executable jar package through Java-jar, the current jar package overwrites all of the values above. In other words, the jar package that follows the-jar is the highest priority, and if the-jar option is specified, All environment variables and the search path made by the command line are ignored. The JVM Appclassloader will only be scoped to the jar package.
There are a number of related security aspects to the executable jar, and you can refer to http://java.sun.com/docs/books/tutorial/jar/to get a complete picture.

This is why the application is packaged into an executable jar package, and no matter how you set up Classpath can not refer to the third party jar package.