Java and JAR commands

-jar parameter setting method when running the application Classpathare you using the Java-jar parameter to run the packaged jar application and find that the application cannot find the content of the third-party class library set up under Classpath? No matter how to set the Classpath parameter is useless, always will report classnotfound error?

When using Java-jar Yourjarexe.jar to run a packaged application, you will find out how to set the-classpath parameter application to find the corresponding third-party class, reporting classnotfound errors. This is actually due to the fact that when running with the-jar parameter, the Java VM masks all external classpath, and only uses the internal class of the Yourjarexe.jar itself as the search scope for the class.

* * Solution * *

A BootStrap class extension solution

The Java command line provides an easy way to extend the bootstrap level class.
-xbootclasspath: Completely replaces the basic core Java class search path.
Not used, otherwise you will be re-writing all Java Core class
-xbootclasspath/a: Suffix behind the core class search path. Common!!
-xbootclasspath/p: prefix is preceded by the core class search path. Infrequently used, avoid
Cause unnecessary conflicts.

The syntax is as follows:
(The delimiter is similar to the classpath parameter, UNIX uses: number, Windows uses; number, UNIX for example)
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 you call Java, the search for the extended class path is automatic. it is always searched. This way, the solution is simple, Copy all of the third-party jar packages you want to use into the EXT directory.

Three User class extension scenarios

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

1. Copy the required third-party jar package to the same directory or to a subdirectory as the executable jar. For example, if the jar is in/usrhome/yourjarexe.jar then you can copy all the jar packages to a similar subdirectory such as the/usrhome directory or/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 a keyword that can be relied upon to run a jar package. For more information, refer to http://java.sun.com/docs/books/tutorial/deployment/jar/downman.html . Note that Class-path is simply an abbreviation for your local machine's classpath environment variable, meaning that this prefix is used to look for the corresponding third-party class/class library in all the classpath directories on your jar-Package execution machine. You are not able to load jar files in your own jar package (or on the network) through Class-path. Because in theory, your jar release package should not be able to include other third-party class libraries (instead, you should use instructions to remind users to get the appropriate support class library). If other third-party libraries (jar, zip, class, etc.) must be packaged directly in your own jar package due to special needs, you must load these third-party libraries according to your own intent by implementing a custom ClassLoader.

The above three methods recommend the first , the extension is good, operation is also the most convenient.
In addition, writing your own classloader to dynamically load class is more complex and advanced technology. Confined to the space, do not repeat. Interested to know can go to Google custom ClassLoader, or refer to my other blog: Let the classpath parameter go away .

Java's security mechanism varies with different JDK versions, affecting many core classes, such as thread, so many large commercial software require a very strict version of the JDK. This is also the case in the release of the application of its own writing, regardless of size, Describe the version of the JDK that was developed and tested.

The methods described herein are tested based on J2SDK 1.4.2_04-b05

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

Attached: Background knowledge

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

To summarize: It is a customizable security mechanism that provides the application layer on the JVM sandbox (sandbox) installation model.

The order in which the Java Virtual Machine (JVM) looks for class

1. Bootstrap Classes

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

2. Extension Classes

Based on the Java extensibility mechanism, it is used to extend the Java core function module. 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 through the command line, or by setting the CLASSPATH environment variable to reference. The JVM is placed in the {java_home}/lib/ Tools.jar to find and invoke the user-level class. The common Javac is also to compile the Java source program by calling Tools.jar to find the user-specified path. This leads to the order or priority of the user class path search.

3.1 Default: Call the current path (.) of Java or Javawa, which is the current directory where the developed class exists
3.2 The path to the CLASSPATH environment variable setting. If Classpath is set, the value of Classpath overrides the default value
3.3 Executes the Java command-line-classpath or-CP value, and if one of these two command-line arguments is established, 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 above values. In other words, the jar package followed by-jar is the highest priority, and if the-jar option is specified, All environment variables and command line-developed search paths are ignored. The JVM Appclassloader will only use the jar package as the search scope.
There are a number of related security aspects to executable jars, which can be fully understood by reference to http://java.sun.com/docs/books/tutorial/jar/ .

This is why the application is packaged into an executable jar package, and no matter how you set it, Classpath cannot refer to a third-party jar package.

Attention

Sometimes we need to read the properties file from Classpath, and for the jar package that runs separately, it needs to be jar/meta-inf/manifest. MF file, so that the program can load files from classpath: classpath

manifest-version:1.0
Implementation-title:
Implementation-version:1.0-snapshot
Implementation-vendor-id:
Built-by:test
Build-jdk:1.7.0_75
Class-path:classes/lib/core-renderer-r8.jar
Created-by:apache Maven
Main-class:batch. Batchmain
Archiver-version:plexus archiver

For running the jar package, the classpath set in the environment variable is not valid

Used to build tools and IDE work, rarely use the command line to execute programs, but occasionally use the command line on the classpath of the settings are to consult the documentation, here to find a detailed and clear instructions for self-examination. Specifically, the classpath is best used "" (under Window System) or "(Under Linux System), this may cause strange error prompts due to special characters containing spaces on the contained jar path., this article has been transferred from Wikipedia, address: Http://en.wikipedia.org/wiki/Classpath_%28Java%29
Setting the path to execute Java programsBasic Usage

Suppose we have a package called Org.mypackage containing the classes:

• HelloWorld (Main Class)
• SupportClass
• Utilclass

And the files defining this package is stored physically under the directory D:\myprogram (on Windows) or/ho Me/user/myprogram (on Linux).

The file structure would look like this:

Microsoft Windows	Linux
d:\ MyProgram | ---> Org\ | ---> MyPackage | ---> Helloworld.class---> Supportclass.class---> utilclass.cl The	/home/user/myprogram/| ---> org/| ---> mypackage/| ---> Helloworld.class---> Supportclass.class---> Utilclass.class

When we invoke Java, we specify the name of the application to Run:org.mypackage.HelloWorld. However we must also tell Java where to look for the files and directories defining our package. We use the following command for so-launch the program:

Microsoft Windows	Linux
Java-classpath D:\myprogram Org.mypackage.HelloWorld

where

• -classpath D:\myprogram Sets the path to the packages used in the program (on Linux, -classpath/home/user/my program)
• Org.mypackage.HelloWorld is the name of the main class

Note that if we ran Java in D:\myprogram\ (on Linux,/home/user/myprogram/) then we would not need to specify the Classpat H since Java implicitly looks in the current working directory for files containing classes.

Adding all JAR files in a directory

In Java 6 and higher, one can add all jar-files with a specific directory to the CLASSPATH using wildcard notation.

Windows Example:

Java-classpath ".; c:\mylib\* "MyApp

Linux Example:

Java-classpath '.:/ mylib/* ' MyApp

Setting The path through an environment variable

The environment variable named CLASSPATH May is alternatively used to set the CLASSPATH. For the above example, we could also with on Windows:

Sometimes you had to check the Java_home also, if it was pointing towards the right JDK version

Set Classpath=d:\myprogramjava Org.mypackage.HelloWorld

Setting The path of a Jar file

Now, suppose the program uses a supporting library enclosed in a Jar file called Supportlib.jar, physically in th E directoryD:\myprogram\lib\.

The corresponding physical file structure is:

D:\myprogram      |      ---> lib            |            ---> Supportlib.jar      |      ---> org            |            -MyPackage                       |                       ---> Helloworld.class                       ---> Supportclass.class                       ---> Utilclass.class

We should use the following command-line option:

Java-classpath D:\myprogram;d:\myprogram\lib\supportlib.jar Org.mypackage.HelloWorld

or alternatively:

Set Classpath=d:\myprogram;d:\myprogram\lib\supportlib.jarjava Org.mypackage.HelloWorld

Setting The path in a Manifest file

Suppose that we program have been enclosed in a Jar file called Helloworld.jar, put directly in the D:\myprog Ram directory. We have the following file structure:

D:\myprogram      |      ---> Helloworld.jar       |      ---> lib\              |            ---> Supportlib.jar

The manifest file defined in this Jar file have this definition:

Main-class:org.mypackage.helloworldclass-path:lib/supportlib.jar

Note:it ' s important that the manifest file ends with either a new line or carriage return.

Also, note that the classpath string in this case describes the location of the Supportlib.jar file relative to the Locati On the Helloworld.jar file, and not as an absolute file path (as it might is when setting The-classpath parameter on t He command line, for example). Thus, the actual locations of the jar file and its support library is irrelevant so long as the relative directory struct Ure between the is preserved.

To launch the program, we can use the following command:

Java-jar D:\myprogram\helloWorld.jar

It is not a necessary to define the Classpath to the program classes, or the "Support library" classes, because it is already defined in Themanifest file.

Caution, it's useless to define the Main class at launch, the manifest of the JAR file must contain a line of the form

Main-class:classname

In order for The-jar the option to work JavaDoc.

The syntax for specifying multiple library JAR files in the manifest file are to separate the entries with a space:

Class-path:lib/supportlib.jar Lib/supportlib2.jar

OS Specific Notes

Being closely associated with the file system, the command-line Classpath syntax depends on the operating system. For example:

• On all unix-like operating systems (such as Linux and Mac OS X), the directory structure have a Unix syntax, with separate File paths separated by a colon (":").
• On Windows, the directory structure have a Windows syntax, and each file path must is separated by a semicolon (";").

This does isn't apply when the Classpath are defined in manifest files, where each file path must being separated by a space (" "), regardless of the operating system.

Diagnose

Application programmers may want to find out/debug the current settings under which the application is running:

System.getproperty ("Java.class.path")

Method One

According to Developrworks said:

Http://www.ibm.com/developerworks/cn/java/j-jar/index.html

Creating an executable JAR

Creating an executable JAR is easy. First put all the application code in a directory. Suppose the main class in the application is com.mycompany.myapp.Sample . You want to create a JAR file that contains the application code and identify the main class. To do this, create a file named in a location (not in the application directory) manifest and include the following line in it:

Then, create the JAR file like this:

That's all you have to do--now you can java -jar execute the JAR file Executablejar.jar.

An executable jar must refer to all other dependent jars it requires through the header of the Menifest file. If an option is used -jar , the environment variable CLASSPATH and any classpath specified on the command line are ignored by the JVM.

Method Two:

Here's a simple one:

Java-djava.ext.dirs=m:\test-jar Test.jar

The associated jar (dependent jar) directory is under M:\test, and Test.jar is the jar that needs to be run

Java and JAR commands