| Home : Course Map : Chapter 4 : Java : Supplements : |
|
Class Loaders
|
| JavaTech |
| Course Map |
| Chapter 4 |
|
Introduction
|
| Supplements
Override/Overload Annotation-J2SE5.0 Java Security Class Loading Class Verifier SecurityManager |
| About
JavaTech Codes List Exercises Feedback References Resources Tips Topic Index Course Guide What's New |
|
To run a java an application, the JVM needs to load the class file with the main() method and the various supporting classes such as the Object class inherited by all Java classes. How does the JVM find a class file and turn its bytes into fields, methods, constructors, and so forth? Most of the work of finding and building a class is done internally by the JVM but the visible part is provided by a class loader, which is an instance of a subclass of the abstract java.util.ClassLoader class (ref.1). A class loader provides the method Class c = loadClass(String className, boolean resolve); to load an instance of Class with the name className. Here the argument resolve indicates whether classes referenced by the class should also be loaded. As discussion the Class class section, the Class instance provides a description of the particular class that the JVM uses to create concrete instances of it. Though part of a JVM is written in C, much of the core capabilities come from base classes written in Java. The JVM needs to load these classes to build itself. The JVM uses a bootstrap (also called primordial) class loader to install the core classes. This loader obtains files from the local disks. It also will load the user classes in files found in the local disks via the CLASSPATH setting. (Actually, as of Java 1.2, there are three default classloaders in a hierarchy beginning with the bootstrap classloader to load core classes, and then an extension classloader for the available extension classes, and the system classloader for classes on the CLASSPATH. See ref. 2 and ref. 3 for details.) However, obtaining classes from other sources, such as the Internet, requires separate classloaders. Custom class loaders can be created by subclassing the abstract ClassLoader class ( ref. 3). This can be particularly useful for cases where classes must be loaded in ways other than reading from a local directory. For example, browser JVMs use an AppletClassLoader object to load classes via HTTP (Hypertext Transport Protocol.) Different applets loaded at the same time may be assigned new classloader objects for each. Note that these supplemental classloaders provide additional security capabilities. The applet class loader, for example, does extra checking on the downloaded class file to reject any pathological code. Also, namespaces can be kept distinct. For example, there is nothing to prevent you from creating a java.lang package in your applet codebase. It might seem that a hacker could thus replace core language classes with diabolical classes. However, since two different classloaders represent the classes, the JVM has no trouble in keeping the classes separate and avoiding the use of fake core classes. Class Loading Procedure The procedure followed to obtain and install a class goes as follows (ref.1):
Particular JVM implementations may vary the order of these steps somewhat. For example, a class might be loaded and cached to speed the processing before it is actually needed. Bytecode verification can be done all at once after the class is first read in or it could be done "on the fly" on individual instructions as they execute. The loading talents of the classloaders is available also for loading other resources such as images, audio files, and so forth. See the Class class discussion. We look more into bytecode verification in the next section. References & Web Resources
Most recent update: Oct. 5, 2005 |
|
Tech |
|
Physics |