The Java Classloader is a part of Java Runtime
Environment that dynamically loads Java classes into the Java Virtual
Machine. Usually classes are only loaded on demand(lazy loading).i.e. There are exactly two cases: When the first instance of the
class is created (MyClass cl=new MyClass()) and static reference to a
class is made (System.out.).
The class loader is responsible for locating libraries, reading
their contents, and loading the classes contained within the
libraries. This loading is typically done "on demand", in
that it does not occur until the class is actually used by the
program. There is a few difference to get the first class running
(which is why you have to declare the main() method as static, taking
a string array as an argument), but once that class is running,
future attempts at loading classes are done by the class loader.
A class with a given name can only be loaded once by a given
classloader(Note: possible with custom class loader .Will discuss
later) .
Each Java class must be loaded by a class loader. Furthermore,
Java programs may make use of external libraries (that is, libraries
written and provided by someone other than the author of the program)
or they may be composed, at least in part, of a number of libraries.
- Bootstrap class loader
- Extensions class loader
- System class loader
This embedded loaders are called the primordial class loaders.The
class loaders are implemented using java.lang.ClassLoader
abstract class.
The bootstrap class loader loads the core Java libraries
(
<JAVA_HOME>/lib
directory). This class loader, which is part of the core JVM, is
written in native code.
The extensions class loader loads the code in the
extensions directories (
<JAVA_HOME>/lib/ext
or any other directory specified by the java.ext.dirs
system property). It is implemented by the
sun.misc.Launcher$ExtClassLoader
class.
The system class loader loads code found on
java.class.path
, which maps to
the system CLASSPATH
variable.
This is implemented by the sun.misc.Launcher$AppClassLoader
class.
Delegation model
The ClassLoader class uses a delegation
model to search for classes and resources. Each instance of
ClassLoader has an associated parent class
loader. When requested to find a class or resource, a ClassLoader
instance will delegate the search for the class or resource to its
parent class loader before attempting to find the class or resource
itself. The virtual machine's built-in class loader, called the
"bootstrap class loader", does not itself have a parent but
may serve as the parent of a ClassLoader
instance.
The class loaders in Java are organized in a tree. By
request a class loader determines if the class has already been
loaded in the past, looking up in its own cache. If the class is
present in the cache the CL returns the class, if not, it delegates
the request to the parent. If the parent is not set (is
Null
)
or can not load the class and throws a ClassNotFoundException
the classloader tries to load the class itself and searches its own
path for the class file. If the class can be loaded it is returned,
otherwise a ClassNotFoundException
is
thrown. The cache lookup goes on recursively from child to parent, until
the tree root is reached or a class is found in cache. If the root is
reached the class loaders try to load the class and unfold the
recursion from parent to child. Summarizing that we have following
order:
- Cache
- Parent
- Self
This mechanism ensures that classes tending to be loaded
by class loaders nearest to the root. Remember, that parent
class loader is always has the opportunity to load a class first. It
is important to ensure that core Java classes are loaded by the
bootstrap loader, which guarantees that the correct versions
of classes such as
java.lang.Object
are loaded. Furthermore it ensures, that one class loader
sees only classes loaded by itself or its parent (or further
ancestors) and it cannot see classes loaded by its children.
The picture illustrates the hierarchy of class loaders. Root
loader is bootstrap class loader which has native
implementation and cannot be instantiated by Java code.
It is followed by extension class loader, which is
primary responsibility to load classes from the extension directories
and provides ability to simply drop in new JVM extensions, without
requiring modification to the user’s classpath. The system
or application class loader responsible for loading classes
from the path specified by the
CLASSPATH
environment variable. This class loader will be returned by the
ClassLoader.getSystemClassLoader()
method.
Why write a Custom ClassLoader?
If the JVM has a ClassLoader, then why would you want to write
another one? Good question. The default ClassLoader only knows how to
load class files from the local filesystem. This is fine for regular
situations, when you have your Java program fully compiled and
waiting on your computer.
But one of the most innovative things about the Java language is
that it makes it easy for the JVM to get classes from places other
than the local hard drive or network. For example, browsers use a
custom ClassLoader to load executable content from a Web site.
There are many other ways to get class files. Besides simply
loading files from the local disk or from a network, you can use a
custom ClassLoader to:
- Automatically verify a digital signature before executing untrusted code
- Transparently decrypt code with a user-supplied password
- Create dynamically built classes customized to the user's specific needs
- to load or unload classes at runtime (for example to load libraries dynamically at runtime, even from a HTTP resource). This is an important feature for:
- implementing scripting languages,
- using bean builders,
- allowing user-defined extensibility
- allowing multiple namespaces to communicate. This is one of the foundations of CORBA / RMI protocols, for example.
- to modify the loaded bytecode (for example, for load-time weaving of aspects when using aspect-oriented programming).
Please visit Custom ClassLoader Example -FileSystemClassLoader to study more about custom class loader.
No comments:
Post a Comment