From the surface, Java's classpath is very simple, but it has always been a root cause of problems and chaos. This article describes the basic knowledge of classpath, which may have problems, and provide a simple ClassPath management tool. During the process of dealing with Java Class Path (Classpath), developers will occasionally encounter trouble. This is because which class loader is actually loaded is sometimes not obvious. The situation is particularly serious when the application's classpath contains a lot of classes and directories. This article will provide a tool that exhibits an absolute path name that is loaded into a class file. 1. ClassPath Basics Java Virtual Machines (JVM) A class that is loaded with the application used by means of a class loader, which is determined based on the need at the time. The ClassPath environment variable tells the class loader where to find the class and user-defined classes provided by third parties. In addition, you can also use the JVM command line parameters-ClassPath to specify the class path for the application, respectively, and the class path specified in the -ClassPath overrides the value specified in the ClassPath environment variable. The content in the classpath can be: the directory of the file (including classes that are not in the package), the root directory of the package (including the packaged class), including the file file (such as a .zip file or .jar file). On the system of UNIX family, each item of the classpath is separated by a colon, and on the MS Windows system, they are separated by a semicolon. The class loader is organized in the form of a delegate level, and each class loader has a parental loader. When a class loader is required to load a class, it will delegate the request to its parent class loader before trying to find a class. The system class loader, that is, the default class loader provided by JDK or JRE installed on the system, is loaded into a class or user-defined class provided by a ClassPath environment variable or -classpath or a -classpath. The system class loader delegate the extended class loader to load classes using the Java Extension mechanism. The extended type loader entrusts the Bootstrap Class Loader to load the core JDK class. You can develop a special type of assembler to customize how JVM is dynamically loaded. For example, most Servlet engines use a customized class-loader that dynamically loads classes that have changed within the directory specified by ClassPath. Special attention must be paid to (it is also surprising), the order of the type loader is loaded is the order of classes of classes in classpath. The class loader starts from the first item of ClassPath, checks each set directory and compressed file, and try to find the class file to be loaded. When the class loader first finds a class with the specified name, it puts the class, and all the remaining items in the classpath are ignored. It looks very simple, right? Second, there may be no matter whether they are willing to admit that beginners and experienced Java developers are the same, they have been at some time (usually in those worst cases) being long, complicated ClassPath spoof. The number of third-party classes and user-defined classes depends on the application gradually increases, and ClassPath has gradually become a place where all possible directories and file names are stacked. At this time, which class is not allowed to be loaded by the class-loaded loader. This problem is especially prominent if the replicated class entry is included in the ClassPath. As mentioned earlier, the class loader always loads the first class with the appropriate name found in the classpath. From the actual effect, it "hides" other kinds of priority with appropriate name but in ClassPath .
If you are not careful, you can easily fell into the trap of this classpath. When you end your long work, in order to let the app use best, the latest class, you join a directory to ClassPath, but at the same time, you have forgotten: another higher priority in ClassPath In the directory, another version of the class is stored! Third, a simple ClassPath tool priority problem is a flat path declaration method with an intrinsic problem, but it is not a problem with only Java's classpath. To solve this problem, you only need to stand on the shoulders of the legendary software.: The UNIX operating system has a which command, specify a name in the command parameter, which will show when this name is executed as a command The path name of the file. In fact, the which command is to analyze the PATH variable, then identify the position of the command for the first time. This should also be a tool for Java path management. Under its inspiration, I started to design a Java tool JWHICH. This tool requires the name of a Java class and then finds the absolute path of the location where the class loader is about to load according to the ClassPath guidelines. Below is an example of JWHICH. It shows that when the Java class loader is loaded with the com.clarkware.ejb.shoppingCartBean class, the first appearance of the absolute path name, the results show that the class is in a certain directory:> Java jwhich com.clarkware.ejb .SHOPPINGCARTBEAN CLAS 'COM.CLARKWARE.EJB.SHOPPINGCARTBEAN' FOUND in '/Home / MCLARK/CLASS/COM/CLARKWARE/EJB/SHOPPINGCARTBEAN.CLASS' The following is the second JWHICH use instance. It shows that when the Java class loader loads a javax.servlet.http.httpservlet class, the first appearance of the absolute path name, the lookup results show that the class is in a file:> Java jwhich javax.servlet. Http.httpservlet class 'javax.servlet.http.httpservlet' found in 'file: /Home/mclar/lib/servlet.jar! /javax/servet/http/httpservlet.class' four, JWHICH work process should accurately measure Which class in ClassPath is loaded first, you must go deep into the generic thinking method.
In fact, it doesn't sound so complicated when the specific implementation - you just ask the type loader! 1: Public class jwhich {2: 3: / ** 4: * Depending on the current classpath setting, 5: * shows the absolute path of the class file containing the specified class, 7: * 8: * @Param ClassName
As a debug auxiliary means, if the specified class cannot be found in the current classpath, the program acquires the java.class.path system properties and displays the current ClassPath (24-28 rows). It is easy to imagine, in the Java Servlet using the Servlet Engine ClassPath, or in the EJB component using the EJB server ClassPath, how to operate the simple code above. For example, if the JWHICH class is loaded by a custom class loader of a servlet engine, then the program will look for the specified class with the class-loader loader of the Servlet engine. If the CERVLET engine's class loader cannot find class files, it will delegate its parent class loader. Generally, when JWHICH is loaded with a certain type loader, it can find all classes that the current class loader and all its parent class loaders are loaded. [Conclusion] If you need to be the mother of all inventions, the tool to help us manage Java classpaths can be said to be late. Many of the Java News Group and the mailing list are stuffed about ClassPath. Now JWHICH provides us with a simple but powerful tool to help us completely play the Java class path in any environment. [Reference Resources] JWHICH full-featured version Include a classpath checker: http://www.clarkware.com/software/jwhich.zip
Sun JDK's official documentation, and instructions on ClassPath on a platform for various official support:
http://java.sun.com/j2se/1.3/docs/t...ingclasses.html
For detailed instructions on setting ClassPath 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
