How to set classpath when running application with java -jar parameter When using java -jar yourJarExe.jar to run a packaged application, you will find how to set -classpath parameter and the application cannot find the corresponding third-party class Report ClassNotFound error. In fact, this is because when the -jar parameter is used to run, the java VM will shield all external classpaths, and only use the internal class of yourJarExe.jar as the search scope of the class.
solution
Extensibility class loader
The extended class loader is generally stored in the {Java_home}\jre\lib\ext directory. When calling Java, the search for the extended class path is automatic. There will always be a search. In this way, the solution is very simple, copy all the third-party jar packages to be used to the ext directory. It will be transparently entered into the loading category.
NOTE: Not recommended, otherwise all JREs need to be migrated and unified and synced!
Bootstrap class loader extension scheme
Use the -Xbootclasspath parameter to load the extended jar package.
The Java command line provides an easy way how to extend bootStrap level classes.
-Xbootclasspath: Completely replace the basic core Java class search path, not commonly used, otherwise all Java core classes must be rewritten (not recommended!).
-Xbootclasspath/a: suffix after the core class search path (recommended)
-Xbootclasspath/p: The prefix is in front of the core class search path, which is not commonly used to avoid unnecessary conflicts. (Not recommended for use)
The syntax is as follows: (The delimiter is similar to the classpath parameter. Unix uses the : number, and windows uses the ; number. Here we take Unix as an example)
java -Xbootclasspath/a:/usrhome/thirdlib.jar: -jar yourJarExe.jar
User class extension scheme
When using -jar to execute the executable Jar package, the JVM sets the directory where the Jar package is located as the codebase directory, and all class searches start in this directory.
So if other third-party jar packages are used, a more acceptable configurable solution is to use the Manifest extension mechanism of the jar package.
Proceed as follows:
Copy the required third-party jar packages to the same directory as the executable jar or a subdirectory. For example: the jar package is in /usrhome/yourJarExe.jar, then you can copy all the jar packages to the /usrhome directory or / usrhome/lib and similar subdirectories.
Modify the Manifest file
Add the following lines to the Manifest.mf file:
Class-Path:classes12.jar lib/thirdlib.jar
Class-Path is a keyword that the executable jar package depends on.
It should be noted that Class-Path is just an abbreviation for the CLASSPATH environment variable of your local machine, that is to say, using this prefix means to search for the corresponding third-party class/class library in all CLASSPATH directories on your jar package execution machine.
You cannot load jar files located in your own jar package (or on the network) through Class-Path.
Because theoretically speaking, your jar release package should not contain other third-party libraries (instead, users should be reminded to obtain the corresponding support libraries through instructions for use).
If other third-party class libraries (jar, zip, class, etc.) must be directly packaged in your own jar package and released together due to special needs, you must implement a custom ClassLoader to load these third-party libraries according to your own intentions class library.
Article source: The network copyright belongs to the original author
The above content is not for commercial purposes, if it involves intellectual property issues, please contact the editor, we will deal with it immediately