Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

Java Tip 105: Mastering the classpath with JWhich

Identify which class will be loaded in your classpath

By Mike Clark, JavaWorld.com, 12/08/00

At one time or another, developers experience frustration when dealing with the Java classpath. It's not always clear which class the class loader will load, especially when your application's classpath becomes inundated with directories and files. In this article, I will present a tool that can display the absolute pathname of the loaded class file.

Classpath basics

The Java virtual machine (JVM) employs a class loader to load classes used by an application on an as-needed basis. The CLASSPATH environment variable tells the class loader where to find third-party and user-defined classes. You can also specify the classpath on a per-application basis with the -classpath JVM command-line argument, which overrides the classpath specified in the CLASSPATH environment variable.

Classpath entries can be directories that contain class files for classes not in a package, the package root directory for classes in a package, or archive files (such as .zip or .jar files) that contain classes. Classpath entries are colon-separated on Unix-type systems and semicolon-separated on MS Windows systems.

Class loaders are organized in a delegation hierarchy, with each class loader having a parent class loader. When a class loader is asked to find a class, it first delegates the request to its parent class loader before attempting to find the class itself. The system class loader, the default class loader provided by the JDK or JRE installed on your system, loads third-party and user-defined classes using the CLASSPATH environment variable or the -classpath JVM command-line argument. The system class loader delegates to the extension class to load classes that use the Java Extension mechanism. The extension class loader delegates to the bootstrap class loader (the buck stops here!) to load the core JDK classes.

You can develop specialized class loaders to customize how the JVM dynamically loads classes. For example, most servlet engines use a custom class loader to dynamically reload servlet classes that have changed in directories specified in a custom classpath.

Of particular importance, and much consternation, the class loader will load classes in the order they appear in the classpath. Starting with the first classpath entry, the class loader visits each specified directory or archive file attempting to find the class to load. The first class it finds with the proper name is loaded, and any remaining classpath entries are ignored.

Sounds simple, right?

Classpath trickery

Whether they would admit it or not, beginner and veteran Java developers alike have at some point (usually at the worst possible moment!) been tricked by the onerous classpath. As the number of dependent third-party and user-defined classes increases for an application, and the classpath becomes a dumping ground for every conceivable directory and archive file, it's not always obvious which class the class loader will load first. This is especially true in the unfortunate event that the classpath contains duplicate class entries. Remember, the class loader loads the first properly named class it finds in the classpath and effectively "hides" all other properly named classes of lower precedence.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.