Java technical article: Use the jwhich tool to manage classpath

On the surface, Java classpath is very simple, but it has always been the root cause of problems and chaos. This article introduces the basic knowledge and possible problems of classpath, and provides a simple classpath management tool.

When dealing with Java classpath, developers may encounter occasional troubles. This is because it is sometimes not obvious which class the classloader actually loads. When the classpath of an application contains a large number of classes and directories, the situation is particularly serious. This article provides a tool that displays the absolute path name of the mounted class file.

I. classpath Basics

The Java Virtual Machine (JVM) uses the class loader to load the classes used by the application. The classes to be loaded are determined based on the current needs. The classpath environment variables tell the Class Loader where to look for third-party classes and user-defined classes. In addition, you can use the JVM command line parameter-classpath to specify the class path for the application, and the class path specified in-classpath overwrites the value specified in the classpath environment variable.

The content in the class path can be: the producer file or. jar file ). On UNIX systems, projects in the classless path are separated by colons. On MS Windows systems, they are separated by semicolons.

The class loader is organized as a delegate level. Each class loader has a parent class loader. When a class loader is required to load a class, it delegates the request to its parent class loader before trying to find the class itself. System class loader, which is the default Class Loader provided by JDK or JRE installed on the system, use the classpath environment variable or the-classpath JVM command line parameter to load a third-party class or user-defined class. The system class loader delegates the extension class loader to load classes that use the Java extension mechanism. The extended Class Loader entrusts the bootstrap class loader to load the core JDK class.

You can develop a special class loader to customize how the JVM dynamically loads classes. For example, most servlet engines use custom class loaders to dynamically load classes that change in the directory specified by classpath.

Note (and surprisingly) that the order in which the Class Loader loads classes is the order in which the classes appear in classpath. The Class Loader starts from the first entry of classpath, checks Each Set directory and compressed file in sequence, and tries to find the class file to be loaded. When the class loader finds a class with a specified name for the first time, it loads the class, and all the remaining items in the classpath are ignored.

It looks simple, right?

Ii. Possible Problems

Whether or not they are willing to admit that beginners and experienced Java developers are the same. They have been cheated by lengthy and complex classpath at some times (usually in the worst cases. The number of third-party classes and user-defined classes that the application depends on increases gradually, and classpath gradually becomes a place where all possible directories and file names are accumulated. In this case, it is no longer obvious which class is first loaded by the class loader. This issue is particularly prominent if classpath contains repeated class entries. As mentioned above, the Class Loader always loads the first class with the proper name it finds in classpath. From the actual results, it "hides" other classes with a proper name but with a lower priority in classpath.

If you are not careful, you can easily fall into the classpath trap. After a long day of work, you add a directory to the classpath to make the application use the best and latest classes, but at the same time, You forget: another version of the class is stored in another directory with a higher priority in classpath!

3. A simple classpath Tool

The priority issue is inherent in the flat path declaration method, but it is not only a problem with Java classpath. To solve this problem, you only need to stand on the shoulders of the legendary software giant: the UNIX operating system has a which command, specifying a name in the command parameter, which displays the path name of the execution file when the command is executed. In fact, the which command analyzes the PATH variable and finds the location where the command first appeared. This should also be a good tool for Java class path management. Inspired by it, I started to design a Java tool jwhich. This tool requires you to specify the name of a Java class, and then find the absolute path of the class to be loaded by the class loader according to classpath instructions.

The following is a jwhich instance. When the Java class loader loads the com. clarkware. EJB. shoppingcartbean class, the absolute path name of the class where it appears for the first time. The search result shows that the class is in a directory:

> JAVA jwhich com. clarkware. EJB. shoppingcartbean

Class 'com. clarkware. EJB. shoppingcartbean' found in
'/Home/mclark/classes/COM/clarkware/EJB/shoppingcartbean. class'

The following is the second jwhich instance. It shows the absolute path name of the class where the class appears for the first time when the Java class loader loads the javax. servlet. http. httpservlet class. The search result shows that the class is in a file:

> JAVA jwhich javax. servlet. http. httpservlet

Class 'javax. servlet. http. httpservlet 'found in
'File:/home/mclark/lib/servlet. Jar! /Javax/servlet/HTTP/httpservlet. Class'

4. jwhich's Working Process

To accurately determine which class is first loaded in classpath, you must go deep into the thinking method of the class loader. In fact, the implementation is not that complicated-you just need to ask the Class Loader directly!

1: Public class jwhich {
2:
3 :/**
4: * according to the current classpath settings,
5: * displays the class file containing the specified class.
6: * absolute path of the location
7 :*
8: * @ Param classname <Class Name>
9 :*/
10: public static void which (string classname ){
11:
12: If (! Classname. startswith ("/")){
13: classname = "/" + classname;
14 :}
15: classname = classname. Replace ('.','/');
16: classname = classname + ". Class ";
17:
18: java.net. url classurl =
19: New jwhich (). getclass (). getresource (classname );
20:
21: If (classurl! = NULL ){
22: system. Out. println ("class" + classname +
23: "'found in'" + classurl. GetFile () + "'");
24:} else {
25: system. Out. println ("class" + classname +
26: "'Not found in'" +
27: system. getproperty ("Java. Class. Path") + "'");
28 :}
29 :}
30:
31: public static void main (string ARGs []) {
32: If (ARGs. length> 0 ){
33: jwhich. Which (ARGs [0]);
34:} else {
35: system. Err. println ("Usage: Java jwhich <classname> ");
36 :}
37 :}
38 :}

First, you must adjust the class name slightly so that the class loader can accept (12-16 rows ). Adding a "/" before the class name requires the class loader to accurately match the class name in classpath, rather than implicitly adding the package name prefix of the calling class. The purpose of converting all "." to "/" is to format the class name into a valid URL resource name according to the requirements of the class loader.

Next, the program queries the resource from the class loader. The resource name must match the formatted Class Name (rows 18-19 ). Each class Object maintains a reference to its classloader object, so it is queried from the class loader that loads the jwhich class. Class. the getresource () method is used to delegate the class loader of the class to return a URL for reading class file resources. Alternatively, when the specified class name cannot be found in the current classpath, class. the getresource () method returns NULL.

Finally, if the specified class can be found in the current classpath, the program displays the absolute path name of the class file containing the class (lines 21-24 ). As an auxiliary debugging tool, if the specified class cannot be found in the current classpath, the program obtains the java. Class. Path System attribute and displays the current classpath (24-28 rows ).

It is easy to imagine how the above simple code works in a java servlet using the servlet engine classpath or in an EJB component using the EJB server classpath. For example, if the jwhich class is loaded by the servlet engine's custom class loader, the program will use the servlet engine's class loader to find the specified class. If the class loader of the servlet engine cannot find the class file, it will delegate its parent class loader. Generally, when jwhich is loaded by a Class Loader, it can find out the current class loader and all the classes loaded by all its parent class loaders.

[Conclusion] if it is necessary to be the mother of all inventions, the tool that helps us manage Java class paths can be said to be a long time late. Java news groups and email lists are filled with many classpath problems. Now, jwhich provides us with a simple but powerful tool to help us completely turn to Java class paths in any environment. [Reference resources]

The full-featured version of jwhich contains a classpath validator:
Http://www.clarkware.com/software/jwhich.zip
The official documents of Sun JDK and descriptions of classpath on various officially supported platforms:
Http://java.sun.com/j2se/1.3/docs/t...ingclasses.html
For more information about classpath settings on Windows and UNIX, see:

UNIX:
Http://java.sun.com/j2se/1.3/docs/t.../classpath.html
Windows:
Http://java.sun.com/j2se/1.3/docs/t.../classpath.html