Managing Java Classpath (Unix and Mac OS X)

The classpath can connect to the Java runtime and the file system. It defines where the compiler and interpreter should look for the. class file to load. The basic idea is that the hierarchy of the file system reflects the hierarchy of the Java package, while the Classpath defines which directory in the filesystem can be the root of the Java package hierarchy.

Unfortunately, the file system is often very complex and relies on the platform, and it does not match well with Java packages. As a result, both new users and senior Java programmers are deeply troubled by the classpath. Yes, it's really not a good side of the Java platform, it lets you get off the clock and still be busy debugging a stubborn little problem.

Of course, using an excellent IDE like Eclipse can reduce some of the difficulties of managing the classpath, but only a few, and the premise must be that everything is normal (but this is unlikely because there will always be some surprises). As a result, every Java programmer must have a thorough understanding of the classpath, only so that the problems that arise in the classpath can be debugged.

In this article, I give you all the information you need to know about the Java classpath (and related source paths) in UNIX, Linux, and Mac OS X. The sister chapter of this article shows similar technologies on Windows. The steps listed in this article can be used as a guide and can solve most of the problems that arise.

Package structure

To master the Classpath, start with the source code. Each class belongs to a package that must adhere to a standard naming convention. Simply put, the name of the package starts with an Upside-down level two 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 for 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 reversed domain name, you need to use the child package name of the single word. Do not use abbreviated forms, and make sure you are spelling correctly. You can use the spelling checker if you want. Most problems related to classpath are caused by a slightly different spelling or abbreviation used in a word in the source code and in a file system. So the best thing to do is to always use a name that is spelled correctly and has no initials.

The entire package name should be lowercase, even if the name is some idiomatic name and abbreviation that is often taken in uppercase elsewhere. Windows usually does not distinguish between capitalization in file names, but Java and some UNIX file systems. If you need to move files between different systems, the problem of capitalization will certainly cause some trouble. Package names must all be made up of ASCII characters. Some compilers also accept package names written with Hebrew, Cyrillic, Greek, or other scripts, but most file systems are not accepted; As you'll see later, the package names must assume the dual tasks of being directory names. Java packages and class names are 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 make the compiler and interpreter unable to find the correct class.

Do not attempt to save cost on package names. In the long run, this will only be harmful and not a benefit. If you need a domain name, buy one. If the name is too long buy a shorter one (I once bought xom.nu such a domain name, so my package prefix is only 6 characters). Do not place the class in the default package (the default package is the package that is given 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 more than once must be placed in a package.

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'll name it project. In this directory, create two more directories: Bin and Src. (Some people prefer to name it build and source, respectively.) ）

Next, in the SRC directory, build a hierarchy that matches the package hierarchy. For example, if the given class is named Com.elharo.math.Fraction, I will place the COM directory in the SRC directory, and then create a Elharo directory in the COM directory, and then place a math directory inside the Elharo directory, and then put it in the math directory Fraction.java, as shown in Figure 1:

Figure 1. Directory structure conforms to package structure

Important: Do not place any content other than source code in the SRC directory. Usually the files put in here are. java files. In some cases, you can also place an. html file (for JAVADOC) or other types of source code. However, you should never place a. class file or any other compiled and generated artifact within this structure. Doing so will only bring trouble. Unfortunately, if not cautious, the Javac compiler will be "knowingly". In the next section, you will be briefed on how to fix this problem.