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):
- Loading includes the following
tasks:
- locate the bytecode file in a disk file, JAR, URL address,
etc.
- read it into the JVM's method area on the heap.
- parse the class data into sections for constants, methods,
fields, etc..
- create an instance of java.lang.Class
to represent the class.
- Linking proceeds through
these 3 steps
- verification - check that the
basic structure and form of the class is proper. Run bytecode
verification.
- preparation - allocate memory for the class data such as static
variables.
- resolution - convert the symbolic references in the class
file, such as variable names, to direct references.
- Initialization
The static variables and constants must be set to either
default or user assigned values. The initialization code is collected
into a special method called <clinit>
that is invoke by the JVM.
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
|