Loading classes - JVM

When the JVM needs access to a particular class, it is up to a class loader to provide the class. Internally each class is represented as an instance of class Class. In JDK 1.2 the built-in system class loader is used to load classes from the local _le system in a platform dependent manner. Additionally, Java programmers can de_ne their own class loaders by subclassing the built-in class ClassLoader and implementing the loadClass method. The system class loader is an instance of this class. The programming interface is as follows:

The class loader takes care of loading and linking, although the name ClassLoader might suggest that it is only responsible for loading and not linking. User de_ned class loaders customize the load phase; class loaders do not di_er in the way they link classes. Linking is done by the method resolveClass.

When a class has to be linked, then it must have been loaded before. When loading a class, all its non-loaded super classes (if any) must be loaded as well, from bottom to top in the inheritance hierarchy. During this step these classes are not linked. When a class is going to be linked, then during the link phase all its non linked super classes (if any) are linked from top to bottom in the inheritance tree.

In the JVM dynamic loading and linking is triggered by (constant pool) resolution. When the machine executes an instruction that references a class, _eld or method, it _rst checks whether the referenced class exists in the sense de_ned below. In case it does not, the JVM invokes the loadClass method of the class loader that de_ned the referencing class, to load the referenced class. If loadClass is called for a class that the loader has already loaded, then the method should simply return that class. The system class loader is implemented in that way. A class exists in the name space of a class loader, if the loader is an initiating or de_ning loader for that class.

As a consequence loadClass methods typically perform the following three steps, reecting the programming interface de_ned above.

  1. If the invoked class loader has already loaded the required class, it _nds the previously de_ned class object using the method findLoadedClass.
  2. Upon successful search, findLoadedClass returns the previously de_ned class object (which is also returned by loadClass).
  3. If findLoadedClass returns null, the system class loader is consulted using the method findSystemClass. This method tries to load the class from the local domain and to link it. If and when loading the class is successful, all (including the previously non-loaded) super classes are required to be loaded, as well. Furthermore, the findSystemClass method links the lass and every non linked super class. If findSystemClass is successful, it returns the loaded and linked class object (which is also returned by loadClass), otherwise findSystemClass throws a ClassNotFoundException.
  4. If no local class can be found (a ClassNotFoundException was thrown in the previous step), the class _le is read from the origin of the referencing class and a class object is constructed from the read bytecodes using defineClass. Incorporating the new class into the run-time state triggers implicit loading of all super classes. Yet, at this time the loaded class and its super classes are not linked. If defineClass completes normally, it returns the constructed class object (which is also returned by loadClass), otherwise defineClass throws a ClassFormatError. In this case loadClass will also throw an exception.

Alternatively the class loader can delegate the loading to another class loader by invoking the loadClass method of that loader.


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

JVM Topics