ClassLoaders « Class « Java Articles

Class loaders are responsible for loading classes into the Java Virtual Machine (JVM). Simple applications can use the Java platform's built-in class loading facility to load their classes; more complex applications tend to define their own custom class loaders. No matter what kind of class loader you're using, however, there are many problems that can occur in the class loading process. If you want to avoid such problems, you need to understand the fundamental mechanics of class loading. When problems do occur, an appreciation of the available diagnostic features and debugging techniques should help you resolve them.

This article kicks off a new series covering a family of topics that I call Java programming dynamics. These topics range from the basic structure of the Java binary class file format, through run-time metadata access using reflection, all the way to modifying and constructing new classes at run time. The common thread running through all this material is the idea that programming the Java platform is much more dynamic than working with languages that compile straight to native code. If you understand these dynamic aspects, you can do things with Java programming that can't be matched in any other mainstream programming language.

Deadlocks of this nature can be resolved using some of the debugging features described in the first article of this series. Setting the IBM Verbose Class Loading option (-Dibm.cl.verbose) when you're running this program will help you understand the class loading sequence that leads to this deadlock. Here's the output.

This article, the third in a series of four, examines some of the more complex and unusual class loading problems that you may encounter in the course of your Java development. The causes of these problems are not always obvious from the symptoms; as a result, they can be difficult and time-consuming to resolve. As with the previous articles in this series, we provide examples to illustrate the problems and then discuss the various resolution techniques.

When a load request is made of a user-defined class loader, that class loader can either immediately attempt to load the class itself, or it can first delegate to some other class loader - only attempting to load the class itself if the delegate fails to do so. A class loader that has been delegated, provided it is not the bootstrap class loader, has the same choice - attempt to load the class itself or delegate to yet another class loader. If a class loader is eventually successful at loading the type, it will be marked as the defining class loader for the type. All of the class loaders that were given an opportunity to load the type are marked as initiating loaders of the type (see Appendix C). If no class loader is successful in loading the type, a java.lang.ClassNotFoundException (or, in certain cases, a java.lang.NoClassDefFoundError) will be thrown.

In Loading/Reloading of Classes and Dynamic Method Invocation, Part 1, I taught you how to write a program that modifies its fundamental behavior at runtime by dynamically modifying, compiling, loading, and reloading classes. I also taught you how to instantiate an object of the newly-loaded class, and how to use reflection to invoke the instance methods belonging to an object of the newly loaded class.

Many larger projects, primarily commercial components, have even adopted the disturbing practice of consuming entire components and bundling them inside of their own JAR. To do this, they mangle the package name to make it unique (e.g., com/acme/foobar/org/freeware/utility) and include the classes directly in their JAR. This has the advantage of preventing any clashes between multiple versions of these component JARs, but at considerable cost. Doing this completely hides the third-party dependencies from the developers. If this process became widespread, it would lead to extreme inefficiencies (both in terms of the size of JAR files and the inefficiency of loading multiple versions of each JAR into one process). The problem with this approach is that if two components depend on the same version of a third component (or can be made to do so), there is no central mediator which can determine this and ensure that the shared component is only loaded once. This is something that we'll be investigating in the next section. In addition to any inefficiencies, it is quite likely that your ability to legally bundle third-party software with your own project may be restricted by the license under which that software is released.

In the CLTester.java skeleton, create an instance of the FileClassLoader. Have the directory name that you use to load files from, come from the command line, as args[0].

This free tutorial provides an overview of the Java? ClassLoader and takes you through the construction of an example ClassLoader that automatically compiles your code before loading it. You'll learn exactly what a ClassLoader does and what you need to do to create your own.

The class loader is an integral part of the Java security architecture. Class loaders separate name spaces to prevent code corruption and name clash problems. They protect the boundaries of the core Java class packages. They establish the protected domains for a loaded class, the basis for runtime authorization. They enforce a search order that prevents core and local classes from being replaced by classes from less trusted sources. The class loader is part of the Java type-safety strategy along with the verifier and runtime security checks.