Shulou(Shulou.com)06/02 Report--

This article mainly introduces "how to understand CLASSPATH". In daily operation, I believe many people have doubts about how to understand CLASSPATH. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubts about "how to understand CLASSPATH"! Next, please follow the editor to study!

The classpath allows you to connect the Java runtime to the file system. It tells the compiler and interpreter where to find the .class file to load. Its basic idea is that the hierarchy of the file system reflects the hierarchy of Java packages, while the classpath defines which directory in the file system can be used as the root of the Java package hierarchy.

Unfortunately, file systems are usually very complex and platform dependent, and do not match the Java package very well. This is especially true in the Windows environment. Java is designed by some Unix experts, so in many ways, this means that it is not well synchronized with Windows conventions. As a result, both new users and experienced Java programmers are aware of the tricky classpath. Yes, it's not the good side of the Java platform, it keeps you busy debugging a stubborn little problem by the time you get off work.

Of course, adopting a good IDE like Eclipse can reduce some of the difficulties in managing the classpath, but only a few, and only if everything is all right (but this is unlikely, because there will always be some surprises). Therefore, every Java programmer must have a comprehensive understanding of the classpath, and only in this way can there be hopes of debugging problems in the classpath.

Packet structure

To master the classpath, you should start with its source code. Each class belongs to a package, and this package must follow standard naming conventions. Simply put, the name of a package starts with an upside-down two-level domain name, such as com.example or edu.poly, followed by at least one or more words to describe the contents of the package. For example, suppose you have a domain name of elharo.com, and if you want to create a Fraction class, you can put it in the following package:

◆ com.elharo.math

◆ com.elharo.numbers

◆ com.elharo.math.algebra.fields

After the domain name is reversed, you need to use a single-word subpackage name. Do not use abbreviations and make sure they are spelled correctly. You can use the spell checker if you want. Most classpath-related problems are caused by the use of a word in the source code and a slightly different spelling or abbreviation in the file system. So the best thing to do is to always use names that are spelled correctly and have no abbreviations.

The entire package name should be lowercase, even if it is some idiomatic name and acronym that is often capitalized elsewhere. Windows is usually not case-sensitive in file names, but Java and some UNIX file systems do. If you need to move files between different systems, the case problem is sure to cause some trouble.

The package name must consist entirely of ASCII characters. Some compilers also accept package names written in Hebrew, Cyrillic, Greek, or other scripts, but most file systems do not; as you'll see later, such package names must have the dual task of acting as directory names. The Java package and class name is Unicode, but many file systems, including FAT, do not recognize Unicode. Unfortunately, there are so many FAT systems. Simply copying files to the system with a different default encoding will prevent the compiler and interpreter from finding the correct class.

Don't try to save money on package names. In the long run, this will only do more harm than good. If you need a domain name, buy one. If the name is too long, buy a shorter one (I once bought a domain name like xom.nu, so my package prefix is only 6 characters). Do not put the class in the default package (the default package is the package given by the system by default if a package statement is not included in the class). If package access is not conducive to communication between objects, you need to add more public methods to the class. Classes that need to be used multiple times must be placed in the package.

Configure Windows

The file extension and path are important for both Java and Windows. So make sure you can see them before you start the next steps. Hiding some filenames is acceptable to end users (but I don't think so entirely), but obviously not for developers. To solve this problem, you need to make some changes to some of the default settings for Windows Explorer.

First open any folder on the Windows desktop. Go to the Tools menu and select Folder Options. In the dialog box that opens, verify that the following three options are selected, as shown in figure 1:

◆ "Display the full path in the address bar" should be selected.

◆ "Display the full path in title bar" should be selected.

◆ "Hide file extensions for known file types" should be cleared.

Figure 1. Windows Explorer option

You may also want to check "Show hidden files and folders", which doesn't have much impact on your Java assignment, but personally, I'd love to see everything I'm working on. Select these options to reveal more details about what you are doing, making it easier for you to debug problems.

Directory structure

The next step is to organize the source files to match the package structure. Create a clean, blank directory somewhere. In this article, I named it project. It would be easier to put this directory at the root level (such as C:\ project). You can also put it on your desktop or in a Documents and Settings folder. But this makes the commands entered longer and more complex, so do this only if you are running Windows XP or higher and do not have administrator privileges. On a single-user system, it is best to have administrator privileges, which greatly simplifies the situation.

In any case, do not put this directory (or any other directory) in the JDK folder (for example, C:\ jdk1.6.0 or C:\ Program Files\ Java\ j2sdk1.5.0_09). The JDK and JRE directories should remain intact after the initial installation.

Within the project directory, create two additional directories: bin and src (some people prefer to name them build and source, respectively).

Next, in the src directory, create a hierarchy that matches the package hierarchy. For example, if I give the class name com.elharo.math.Fraction, I will place the com directory in the src directory, then create an elharo directory in the com directory, then put a math directory in the elharo directory, and finally put Fraction.java in the math directory, as shown in figure 2:

Figure 2. Directory structure that conforms to the package structure

Important: do not place anything in the src directory other than the source code. Usually the files placed here are .java files. In some cases, you can also place .html files (for JavaDoc) or other types of source code. However, you must never place .class files or any other compiled and generated artifacts within this structure. Doing so will only lead to trouble. Unfortunately, if you are not careful, the javac compiler will "knowingly commit it". In the next section, we will describe how to fix this problem.

Compile

Compiling Java code requires some tricks because you have to keep track of the following aspects that are relevant but different:

The target file that ◆ is compiling.

The ◆ compiler looks for the directory where the target file imports the .java file.

The ◆ compiler looks for the directory where the target file imports the .class file.

The directory where the ◆ compiler places the compiled output.

By default, the javac compiler considers all of the above directories as current directories, which is not what you want. Therefore, you need to specify these elements explicitly at compile time.

The file to be compiled

The first file specified to compile is the .java file, given as the entire path from the current directory to the file. For example, suppose the current directory is the project directory shown in figure 1. This directory contains the src directory. This src directory contains the com directory, while the com directory contains the example directory, and the example directory contains the Fraction.java files. Compile it on the following command line:

C:\ project > javac src\ com\ elharo\ math\ Fraction.java

If the path is incorrect, an error message like this is given:

Error: cannot read: src\ com\ example\ mtah\ Fraction.java

If such an error message appears, you need to check all parts of the path to make sure they are spelled correctly. In this example, the error message shows that the second and third letters of math are reversed.

If no spelling errors are found, check that the file is where it should be by issuing a dir command as follows:

C:\ project\ src > dir src\ com\ example\ math

Ls: src/com/example/math: No such file or directory

The problem is usually caused by a misspelling of the path, but it may also be due to the wrong current directory. In this case, you need to check whether the current working directory is the project directory. Check the text between C: and > on the command line to confirm that the current directory is the expected directory. In this case, the current directory is C:\ project\ src, while the expected directory is C:\ project.

Where does the output go?

Assuming there are no syntax errors, javac places the compiled .class file in the same directory as the corresponding .class file. This is not what you want. Mixing .class and .java files often makes it difficult to clean up compiled files because you are likely to accidentally delete .java files that should have been retained. This often makes it difficult to clean up builds and can lead to version problems. When publishing a binary, it can also be difficult to archive only compiled .class files. Therefore, you need to tell the compiler to put the compiled output in a completely different directory. The-d switch is used to specify the output directory (commonly referred to as bin, build, or class):

C:\ project > javac-d bin src\ com\ elharo\ math\ Fraction.java

The output will look like figure 3. Notice that javac has created a complete com\ elharo\ math directory hierarchy. You don't need to build it manually.

Figure 3. Parallel source and compiled hierarchy

Source path

The source path is the directory where Java looks for the source files. In this case, it is the src directory. The directory must contain a hierarchy of source files that can be placed in their own directories. So it is not the com directory or the src\ com\ elharo\ math directory.

Many projects use more than one class and package. They are connected with the full package-qualified class name through an import statement. For example, suppose you create the MainFrame class in the com.elharo.gui package, as shown in listing 1:

Package com.elharo.gui; import com.elharo.math.*; public class MainFrame {public static void main (String [] args) {Fraction f = new Fraction (); / /...}}

Listing 1. Classes in one package can be imported into classes in another package

This class uses the com.elharo.math.Fraction class in a package that is different from the package where the MainFrame class is located. The source settings should now look like figure 4 (I removed the compiled output from the previous step. But it doesn't matter, because I can always recompile it.

Figure 4. The source structure of several packets

Now let's see what happens when you try to compile MainFrame.java as before.

C:\ project > javac-d bin src\ com\ elharo\ gui\ MainFrame.java src\ com\ elharo\ gui\ MainFrame.java:

3: package com.elharo.math does not exist

Import com.elharo.math.*

^

Src\ com\ elharo\ gui\ MainFrame.java:7: cannot find symbol

Symbol: class Fraction

Location: class com.elharo.gui.MainFrame

Private Fraction f = new Fraction ()

^

Src\ com\ elharo\ gui\ MainFrame.java:7: cannot find symbol

Symbol: class Fraction

Location: class com.elharo.gui.MainFrame

Private Fraction f = new Fraction ()

^

3 errors

The reason for the error is that while javac knows where to find MainFrame.java, it doesn't know where to find Fraction.java (you might think it should be smart enough to recognize matching hierarchies, but this is not the case). In order to give it some clues, the source path must be specified. Use the source path to specify which directories the compiler should go to find the hierarchy of the source files. In listing 2, the source path is src. So I used the-sourcepath option, as follows:

C:\ project > javac-d bin-sourcepath src src\ com\ elharo\ gui\ MainFrame.java

If you compile the program now, there will be no errors and the output shown in figure 5 will be generated. Note that javac also compiles the file Fraction.java,Fraction.java is referenced by the currently compiled file.

Figure 5. Multi-class output

Compile multiple directories in the source path

There can be multiple directories in the source path, separated by semicolons, but this is usually not necessary. For example, if I want to include the local src directory and the C:\ Projects\ XOM\ src directory that holds the source code of another project, I can compile like this:

C:\ project > javac-d bin-sourcepath src;C:\ Projects\ XOM\ src

Src/com/elharo/gui/MainFrame.java

This command does not compile every file found in the two hierarchies. It compiles only files referenced directly or indirectly by a single .java file, which must be compiled.

More often, use a single source directory for .java files and multiple directories for classes or JAR archives with precompiled third-party libraries. And that's what classpath is for.

Set classpath

In large and medium-sized projects, it can be time-consuming to recompile each file every time. To reduce this compilation burden, separate parts of the same project can be compiled and stored in different bin directories. These directories are added to the classpath.

There are several ways to add a class to the classpath. However, you can only use the-classpath command line switch. For example, suppose I want to import a file from another project that was previously compiled into the directory C:\ lib\ classes, then I will add-classpath C:\ lib\ classes to the command line, as follows:

C:\ project > javac-d bin-sourcepath src-classpath C:\ lib\ classes

Src\ com\ elharo\ gui\ MainFrame.java

Now suppose you need to add two directories: C:\ project1\ classes and C:\ project2\ classes, which can be separated by semicolons, as follows:

C:\ project > javac-d bin-sourcepath src

-classpath C:\ project1\ classes;C:\ project2\ classes

Src\ com\ elharo\ gui\ MainFrame.java

Of course, you can also use various relative path formats you like. For example, if project1 and project2 are siblings of the current working directory (that is, they have the same parent directory), I would reference them like this:

C:\ project > javac-d bin-sourcepath src

-classpath..\ project1\ classes;..\ project2\ classes

Src\ com\ elharo\ gui\ MainFrame.java

So far, I have assumed that the program is completely independent and does not use any separate compiled third-party libraries. If you need to use third-party libraries, you must also add them to the classpath. Libraries are usually in the format of JAR files, such as junit.jar or icu4j.jar. In this case, what needs to be added to the classpath is the JAR file itself, not the directory containing the JAR file (essentially, the JAR file can act as a directory containing compiled .class files). For example, the following command adds three items to the classpath: the directory C:\ classes, the file icu4j.jar in the current working directory, and the file junit.jar in E:\ lib:

C:\ project > javac-d bin-sourcepath src

-classpath C:\ classes;icu4j.jar;E:\ lib\ junit.jar

Src\ com\ elharo\ gui\ MainFrame.java

JAR files are used only for .class files and classpath, not for .java files and source paths.

Run the program

Now that you have successfully compiled the program, you can run it. Running is similar to compiling, but simpler. When you run the program, you only need to specify two things:

◆ classpath

◆ the fully qualified package name of the class that contains the main () method

There is no need to specify the source path.

Usually the classpath here is the same as the classpath used by the compiler, except that there is an extra directory where the compiled output is placed. For example, if the compile command looks like this:

C:\ project > javac-d bin-sourcepath src

-classpath C:\ classes;E:\ lib\ junit.jar

Src\ com\ elharo\ gui\ MainFrame.java

And the main () method is in the class com.elharo.gui.Mainframe.java, you can run the program like this:

C:\ project > java-classpath C:\ classes;E:\ lib\ junit.jar

Com.elharo.gui.MainFrame

It is important to note that the last item on the command line is the class name. It is not a file name, nor is it .java or .class. The class must be found somewhere in the classpath.

Other places where the class may exist

I strongly recommend that you always specify the classpath explicitly at compile and run time. You can also put the files somewhere else so that they can be added to the classpath and found by the javac compiler and java interpreter. This saves some typing, but it takes a lot of debugging time when (note not if) you inadvertently put an older version of the class in the classpath.

In this section, we will show several places where classes often hide, and these classes are likely to pop up unexpectedly in the classpath and cause problems. This is more common on machines that are not under your control, such as servers.

Current working directory

The compiler always sets the current working directory (.) Add to the classpath, regardless of whether you have explicitly asked to do so. It's easy to forget what you have and don't have in the same directory as your directory. Therefore, try to avoid putting any classes or hierarchies in the project or home directory. Instead, place .java files and .class files in the src directory and the bin directory, respectively.

CLASSPATH

After a while, you will find it too cumbersome to manually add bin directories and JAR archives to the classpath. At this point you may want to use the CLASSPATH environment variable. You can add directories and JAR archives to the CLASSPATH environment variable only once, and then you don't have to type these paths every time you run javac or java.

Be sure to resist this temptation. In doing so, there will be a problem once the wrong class or wrong version of the class is loaded. And the debugging time caused by accidentally loading the wrong class is often a hundred times longer than the typing time saved. There are better ways to avoid typing and automatically handle classpath.

Jre\ lib\ ext

JAR archives placed in the jre\ lib\ ext directory are added to the classpath of all applications running through the virtual machine. This seems convenient, but in fact it has the same long-term potential problems as adding directories to the CLASSPATH environment variable. Sooner or later (usually soon), you will load an incorrect version of the class in an unexpected place and spend a lot of debugging time on it.

The problem is even more serious when deploying a server-side application. Make sure that the server you are deploying to does not have any additional JAR in its jre\ lib\ ext directory. If you are not familiar with error symptoms and do not know how to find them, problems caused by the wrong version of the JAV archive file in the classpath can be very difficult to debug. To avoid these problems, some frameworks even write their own class loaders to bypass the usual class loading mechanism of Java code.

Jre\ lib\ endorsed

The JAR file placed in the jre\ lib\ endorsed directory is also added to the classpath of all applications running through the virtual machine. The difference is that the files here are actually placed in the bootclasspath instead of the usual classpath and can replace the standard classes that come with JDK. This approach is particularly useful for updating XML parsers and fixing bug in VM.

However, as mentioned earlier, this approach seems very convenient, but in fact there are long-term potential problems, and for the same reason. If you need to replace the JDK class, you can use the-Xbootclasspath/p option at run time to avoid accidentally loading the wrong version of the class.

C:\ project > java-classpath C:\ classes

-Xbootclasspath/p:xercesImpl.jar com.elharo.gui.MainFrame

Automatically manage classpath

Be proficient in using hammers before you want to use an electric nail gun, and similarly, you should be able to manage these classes manually before trying to use more powerful automatic management tools. If you have mastered the command-line toolset, you can use other tools to automate some of the tedious processes required by the source and classpath. Most of these tools also require you to organize files as described in this article.

IDE

Many development environments such as Eclipse and NetBeansMost can assist in automatic classpath management. For example, when you change the name of a package, Eclipse can move the corresponding .java file accordingly, as shown in figure 6:

Figure 6. Quickly fix classpath in Eclipse

Keep in mind that these IDE are at the top of the file system and must be set up correctly, especially if you need to integrate with other tools and other IDE. The biggest contribution of these tools is to replace command-line switch parameters with GUI dialogs, tree views, and tabs, but their basic file structure is the same.

Ant

Ant is the de facto standard tool for automating the build process. Unlike putting directories in jre\ lib\ ext or the CLASSPATH environment variable, Ant really allows you to create an one-step build process. But you still need to set the classpath in Ant build.xml and manually place the source files in the correct directory. But at least for now you don't have to reassign it every time you compile.

Maven

Maven goes a step further than Ant in organizing and automating the build process. Maven provides a reasonable default setting that allows you to build a simple project by adding a few lines of code and putting the source files in a location where Maven can find them. You still need to adjust the file system and package hierarchy. Maven is also good at managing the dependencies of third-party libraries, although it is not as easy to customize as Ant.

At this point, the study of "how to understand CLASSPATH" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.