Download ClassLoader

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts
no text concepts found
Transcript
Understanding the Java ClassLoading Mechanism: extend the
Java platform
This article was published in the Java Developer's Journal, August 2003. The
journal discussed a key component known as the ClassLoading mechanism that is used
by the Java Virtual Machine (JVM). What makes the ClassLoading mechanism so
valuable is its custom usability to achieve functionality not normally achieved by any
ordinary Java programs. The purpose of the JVM is very valuable when running and
designing Java related programs. The JVM is used for loading and executing java code
in classes using the mechanism mentioned, “ClassLoader”. When the IVM first
initializes, it doesn’t need to know anything about any classes loaded at runtime from the
help of the ClassLoading function; therefore, when implementing Java-based containers,
it is very important to designers to know detailed information of how the ClassLoading
function operates.
The class file that is loaded into the ClassLoading mentioned above is a very
small amount of execution. How the ClassLoading mechanism works is pretty
1
straightforward process. Every Java class file contains a binary representation of that
class including everything the class does. The ClassLoading function simply takes this
binary representation of these class files and locates the byte codes needed to be loaded.
Then, it takes the loaded byte codes to be read. Finally, creates an instance of the
java.lang.Class class. When the IVM is initialized, nothing is started, this process is the
first step used by the IVM to get started.
Technically, the starting class file that
runs a program is executed first along
with all its interfaces and other classes
that are needed in the program. The
JVM doesn’t load just any classes, it
only loads classes when they are needed.
Therefore, the IVM doesn’t need to
know any classes to load up at startup.
This type of “lazy loading” is a key aspect to the lava platform.
On the Java 2 runtime environment there exist several instances of the
ClassLoader method, each of these ClassLoader methods also load classes that are from
different code repositories. Figure 1 shows an example of how this works with two
examples of ClassLoader. Using examples, in most cases the Java API classes are loaded
using the Bootstrap class loader and the Application classes are loaded using the System
ClassLoader. Figure depicts a parent-child relationship between ClassLoaders. The
Bootstrap ClassLoader is the only ClassLoader without a parent ClassLoader.
The figure shows how Bootstrap is its own root of the tree and branches from there.
2
Described below is a short step-by-step algorithm that is ran by a ClassLoading function
when the client wants to load a class:
1) First, to make sure a process is not duplicated, a simple check is ran to make sure
the class was not already loaded by the ClassLoader. If, for some reason, the
class was loaded already, then step one is already completed and then the JVM
takes over.
2) If a previous ClassLoader has not loaded the class already, the process is then
delegated to the ClassLoader’s parent before it can load the class. As seen in
figure 1, delegation goes clear as far as the bootstrap ClassLoader but not any
further.
3) A ClassLoader will try to search for a certain class usually only when a parent
fails to return the class itself. Since this situation can occur, ClassLoaders have
already defined locations to search for the missing class.
4) If all else fails and the class is
still not found, the notorious
3
“java.lang.ClassNotFoundException” is thrown.
In Figure 2 is a snippet of what methods for the ClassLoader would look like under the
Java 2 API by extending the java.lang.Class Loader class.
Before Java 2, implementing the ClassLoader method was fairly difficult and took time.
Therefore, in Java 2 they came up with the parent delegation model to solve this problem
as can be seen in Figure 1.
However the algorithm
mentioned above is just the
standard algorithm, the great
thing about the ClassLoading
function is its ability to custom
program the algorithm. There
is a method the ClassLoader
uses called findClass method.
This is an original method used
in step 3 in the above algorithm.
4
When a custom ClassLoader is created, it overwrites this findClass method with a custom
way of finding and locating files thus resulting in a smoother implementation of a
ClassLoader
Figure 3 shows a listing of a piece of code of a custom ClassLoader program would look
like to overwrite this findClass method. What the ClassLoader uses is the findClass
method to find byte-codes of a class file. When these classes do get located and loaded,
they can be now modified before calling the defineClass.
The are several kinds of ClassLoaders existing to assist the JVM with different
types of so called trust levels used in how they load classes into the JVM. For example,
the Bootstrap ClassLoader has the highest trust level for its use in loading up the Java
runtime libraries. Then the lower level of trust is used for user-defined ClassLoaders.
How this happens, in either form, is when the class is loaded, the ClassLoaders imbeds
permission rights to each class as it executes. To accomplish this task the custom
ClassLoader should extend the java.security.SecureClassLoader class and use the method
defineClass to be able to take a java.security.CodeSource object as a parameter.
The JVM relies heavily on the ClassLoader function in bringing in code, and the
build of the two mechanisms have a very strong security structure to protect the JVM
from being able to communicate with the ClassLoader. It accomplishes this task when
the ClassLoader loads a specific class and it gives it a unique name. When the runtime is
ready to execute, it can identify this unique package name and what ClassLoader was
used to create it.
References

Java Developer's Journal, August 2003 v8 i8 p10(3)
5
“Understanding the Java classloading mechanism: extend the Java platform.”
(Java Architecture) Rohit Chaudhri.

Liang, S., and Barcha, G. "Dynamic Class Loading in the Java Virtual Machine":
www.java.su.com/people/grabracha/classloaders.pdf

Venners, B. (2000).”Inside the Java Virtual Machine.” McGraw-Hill Osborne
Media.

Neward, T. (2000). “Server-Based Java Programming.” Manning Publications
Company.

Gong, Li. "Secure Java Class Loading"
http://java.sun.com/people/gong/papers.ieeeic98.pdf

The Java Servlet Specification:
http://jcp.org/aboutJava/communityprocess/first/jsr154/
6