*********************************************************** *********** Description: 1 : Http://www.kevinboone.com/classpath.html. However, there is no author above, so it cannot be concluded whether or not, can only invite the insider to make up, as a respect for others. Also reprint this translation, you must add this description. 2, this article is translated in 2003.04.23, and released in the future garden java version of Beihang, because several netizens asked at the same time asked about ClassPath, I didn't want to answer one by one, and released this article on the hand. At that time, the translation was very scribbled, and the previous post to 9CBS is working. *********************************************************** ***********
Mastering the java classpath
Bad guys translation
1, the importance of the Class search path
Understanding that the Class search path is important for all Java developers, but the extensive use of IDE covers this technology, making everyone universally understanding it, and even a lot of old birds. This issue is developing
Applications for publishing (deshought for Distributed Applications, but seem to translate "" distributed applications "a bit obscured), because the system environment at the application run may be large and the development is very different.
This article describes how certain Java classes are referenced by other code, how to locate these classes using class search paths (Class Search Path) when referenced by other code. This uses a very simple example - two classes in the same package - specifically described. We will compile these two classes in different ways, depending on the set of ClassPath, compile may succeed.
For the clearest description, we will use only the command line tool to compile. Interactive development tools have their own way of operating ClassPath, which varies depending on the product.
As for the Java compiler to position the class required for compilation, or by JVM is running at runtime, these two methods have no essential difference. However, the compiler can compile the required classes from the source code, while JVM can't. In the following example, we do it with the compiler, but the implementation of the runtime is also totally similar.
2, example
This example has two small classes: com.web_tomorrow.cptest1 and com.web_tomorrow.cptest2, as shown below: package com.web_tomorrow; public class cptest1 {public static void main (string [] args) {system.out. Println ("Run cptest1.main ()");}}
Package com.web_tomorrow; public class cptest2 {public static void main (string [] args) {system.out.println ("run cptest2.main ()"); cptest1 cpt1 = new cptest1 ();}}
One of the most basic rules of the Java code organization is `package name = directory name '(" package name = directory name "). We will establish a corresponding directory structure for these two classes, they are in the package com.web_tomorrow, so we create directory com / web_tomorrow to save source code: [root] com Web_tomorrow cptest1.java cptest2.java in this article I use symbols `[root] 'to indicate any directory of the above structure, that is, the location of the root directory is determined by you. Of course, this will be different from the way these files are installed.
3 Basic principle
Let's try to compile cptest1.java with command line tool Javac. In order to completely disabate the search path (to prevent the existing settings affect this example), we add options `-classpath" "on JavaC.
As the first test, we will first change to the directory where cptest1.java is located, and try to compile with Javac and file names. CD [root] / com / web_tomorrowjavac -classpath "" CPTEST1.JAVA
The operation is successful because the compiler can find cptest1.java (it is in the current working directory), and CPTest1 does not reference any other class. Output file cptest1.class under the same directory of CPTEST1.JAVA, because you don't give any information to the compiler to make it other processing. So far, it has always been very good. Now let us use the same way to try CPTEST2. Still in the web_tomorrow directory, execute the command: javac -classpath "" cptest2.java
Although the directory is still the directory, CPTEST1 and CPTEST2 are also in the same package, but this time has failed. The error message may be like this: cptest2.java: 7: Cannot Resolve Symbolsymbol: CLASS CPTEST1 LOCATION: CLASS COM.WEB_TOMOW.CPTEST2 CPTEST1 CPT1 = New Cptest1 (); ^
One of the differences between this and last success is the reference to cptest2 in cptest1: cptest1 cpt1 = new cPTEST1 ();
What happened this time? When the compiler encounters a reference to cp1test, it will think that the CP1TEST class is in the same package with the currently compiled CP2Test class. This assumption is correct, so the compiler is looking for
Look for com.web_tomorrow.cp1test, but it can be found, because we have specified the class search path "" (that is, empty).
You may think that you can solve this problem when you tell the compiler to find this in the current directory. In UNIX and Windows systems, the standard symbols of the "Current Directory" are a bit number (.), That is, such a life
Order: javac -classpath "." Cptest2.java
Fail Againt! As just now, the problem is now, although cptest1.java is in the current directory, but its category is not cPTEST1, but com.web_tomorrow.cptest1, the compiler will look for directory COM / Web_Tomorrow in the current directory. That is, it is looking for a Java source file or class file in the directory [root] / com / web_tomotom / COM / Web_Tomorrow, and they do not exist at all, so errors. In order to make the compiler work normally, we cannot let the class search path points to the directory containing cptest1, but in accordance with the rules of the `package name = directory name 'in the Java standard, give the class search path Specify the compiler to find the root directory of the cptest1. This will work, although I don't look good: javac -classpath "../ .." cptest2.java
After considering how it becomes unclear, look at this example (still in the same directory) Javac-ClassPath "" cptest1.java cptest2.java
Although ClassPath is empty, this time it works. This is because the Java compiler finds all source code in the command line to find references. If you want to compile multiple classes in the same directory, there is a very simple way: javac -classpath "" * .java
'* .java' extends to list all .java files in the current directory. This shows why it will succeed once, and the same file is a compilation.
Compiling CPTEST2 has a more convenient method: CD [root] javac -classpath "." COM / Web_Tomorrow / CPTest2.java
This time we specify a complete path for cptest2.java, and use '.' In the -classpath option. Also, we didn't tell the compiler to find files in the current directory, but let it start from the current directory. Because the class we have to find is com.web_tomorrow.cptest1, the compiler will be in ./com/web_tomorrow (that is, the COM / Web_Tomorrow subdirectories under the current directory). This is the correct location of cptest1.java.
In fact, although I only specified CPTest2 on the command line, but in fact, cPTest1 will also be compiled. The compiler found this .java file in the correct location, but it can't determine if this .java file contains the correct class, so it compiles this file. But please note if: cd [root] javac -classpath "." COM / Web_Tomorrow / CPTEST1.JAVA
Will not cause CPTest2.java to be compiled because the compiler compiles CPTEST1, it is not necessary to know anything in CPTEST2.
The case of class files and .java files are separated by all successful examples of all successful examples of the output .class files in the same location, which is a relatively simple mode, which is very extensive. But many developers like to separate the source files and generated files, so it must tell the compiler to maintain different directories for .class files. Let's take a look at what is the impact of this search path.
First we delete all the .class files generated by several examples. We also have a new directory to store the generated .class file. The operation of the command line mode is as follows: CD [root] RM COM / Web_Tomorrow / *. Classmkdir Classes
If you use the Windows system, don't forget to replace '/' to replace '/', the current directory structure is as follows: [root] com Web_tomorrow cptest1.java cptest2.java classs Now compiles cptest1.java, specify the target directory of the specified class file ( By -D option) CD [root] javac -d classes -classpath "" COM / Web_Tomorrow / CPTEST1.JAVA
Successful, but you will notice that .class files are not directly placed in the classes directory, but there is a new directory structure: [root] com web_tomorrow cptest1.java cptest2.java class com Web_tomorrow cptest1.class
The compiler establishes a directory structure that meets the package structure, which is useful, we will see it immediately. When we start compiling cptest2.java, we have two options, the first is the same as above, let the compiler also
Compile a CPTEST1; the other is to specify the "ClassPath option to specify the" Class file that is just compiled, this method is better, because we don't have to compile a CPTEST1: CD [root] javac -d classes -classpath classes COM / Web_Tomorrow /Cptest2.java
After completing, our directory structure is as follows: [root] com Web_tomorrow cptest1.java cptest2.java classes com Web_tomorrow cptest1.class cptest2.class
Of course, we can also compile two .java files in the same command, the result is exactly the same.
4, JAR packaging file in classpath
The Java compiler and operating environment can not only search classes in a separate file, but also in the JAR package file. A JAR packaging file can maintain its own directory structure, Java performs search in the same way as the normal directory structure, `Directory Name = Package Name '. Since JAR itself is a directory, the path must reference the JAR itself when the JAR packaging file is included in the class search path, not the directory there is. If I have a jar myclasses.ja under the directory / myclasses, I need to specify: javac -classpath/myclasses/myclasses.jar ... is not just the directory myclasses.
5, multiple class search directories
In the above example, each time we only let Javac searched in a directory. In actual work, your class search path will contain a lot of directories and JAR files. Javac's -classpath option allows you to specify multiple locations, but please note that its specific syntax is slightly distinct in the UNIX system and Windows systems. In the UNIX system: Javac-ClassPath Dir1: Dir2: Dir3 ... and Windows system is: javac -classpath dir1; dir2; dir3 ...
This is because Windows uses a colon (:) as part of the file name, so it cannot be separated as a file name. Of course, directory separators are different: Unix's forward slash (/) and backslash of Windows (/). 6, system classpath
In addition to specifying a class search path in the Javac command, we can also use the 'System' Class Path. If you do not specify a specific path in the command, both the Java compiler and JVM use the system path. In UNIX and Windows systems, the system path is set through environment variables. For example, in the Linux system using Bash Shell: classpath = / myclasses / myclasses.jar; Export ClassPath in Windows: Set ClassPath = C: /myClasses/myclasses.jar
This is a good way to temporarily change the system variable ClassPath, but if you want these changes, you need to make some modifications for your system. For example, in the Linux system, I will put this command in my directory. Bashrc. In Windows 2000 / NT, you can modify it through the 'Control Panel'.
If you have a lot of JARs ready to use, setting the system variable ClassPath is particularly important. For example, if I use Sun's J2EE reference to implement the EJB app, all EJB-related classes are released in a JAR package file called "j2ee.jar", I hope this JAR has always been in the class search path. In addition, there are many people hope that the search path always contains the current directory regardless of what the current directory is. So there is such a line in my .bashrc file: classpath = / usr / j2ee / j2ee.jar:.; Export ClassPath where `. 'Refers to' current directory '
It is easy to see the -classpath option in the command line overwrite the default system class path; it is not extended but override. So if we need to include the default system path, how do you add some time? We can simultaneously list the default values through the -classpath option and we need additional parts. A better way is to reference system variables claspath. Of course, this syntax is different for Windows systems and UNIX systems. On UNIX: Javac-ClassPath $ ClassPath: Dir1: Dir2 ... where $ ClassPath extends to the system variable ClassPath. On Windows: Javac-ClassPath% ClassPath%; Dir1: Dir2 ...
