This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
12.7 Unloading of Classes and Interfaces An implementation of the Java programming language may unload classes. A class or interface may be unloaded if and only if its defining class loader may be reclaimed by the garbage collector as discussed in �12.6. Classes and interfaces loaded by the bootstrap loader may not be unloaded.
There is a nice resource for this matter at artima.com . There you can read some chapters of the book Inside the Java 2 Virtual Machine by Bill Venners. In a Java 2 VM typically three class loaders are created are VM starp up: The boostrap, the extension one and the class path one. The boostrap is built in the VM, it is not an object in the heap. All the others are Java objects. There is a hierarquy of class loaders: at the top the bootstrap class loader, this is the father of the extension class loader; at last this the father of the class path loader. If the class path loader is the last created by a given JVM implementation, the class path loader is designated as the System class loader. The System class loader is responsible for loading the classes of an application. Any class loader created by an application has the System class loader as its paren t by default. The class path loader is responsible for looking up the classes in the class path. The extension class loader is responsible for looking up classes in the extensions directories. The boostrap class loader loads classes from the API. The class loaders created by the JVM are chained as described. In a Java 2 application, the class loaders created by the application are "well mannered" if they are chained in the previous hierarqhy, AND if they ASK its parent to a load a class before trying them themselves doing so. Because all the class loaders should have the boostrap class loader at is top, and all of them should ask its parent first them trying themselves; all the classes are looked up first in the API, after that in the extensions directory and at last in the class path. In this way a class that resides in the API can not be replaced by a hacked-one placed anywhere else (other directory, or in Internet). So under normal circumstances the classes loaded by the boostrap class loader are those you can read about in the Java API.