Dynamic Class Loading in the Java
TM
Virtual Machine
Sheng Liang Gilad Bracha
Sun Microsystems Inc.
901 San Antonio Road, CUP02-302
Palo Alto, CA 94303
f
sheng.liang,gilad.bracha
g
@eng.sun.com
Abstract
Class loaders are a powerful mechanism for dynamically
loading software components on the Java platform. They
are unusual in supporting all of the following features:
laziness, type-safe linkage, user-defined extensibility, and multiple
communicating namespaces.
We present the notion of class loaders and demonstrate
some of their interesting use s. In addition, we discuss how to
maintain type safety in the presence of user-defined dynamic
class loading.
1 Introduction
In this paper, we investigate a n important feature of the
Java virtual machine: dynamic class loading. This is the
underlying mechanism that provides much of the power of
the Java platform: the ability to install software components
at runtime. An example of a component is an applet that is
downloaded into a web browser.
While many other sys tems [16] [13] also support some
form of dynamic loading and linking, the Java platform is
the only system we know of that incorporates all of the
following features:
1. Lazy loading. Classes are loaded on demand. Class
loading is delayed as long as possible, reducing mem-
ory usage and improving system response time.
2. Type-safe linkage. Dynamic class loading must not
violate the type safety of the Java virtual machine.
Dynamic loading must not require additional run-time
check s in order to guarantee type safety. Additional
link-time checks are acceptable, because these checks
are performed only once.
3. User-defina ble class loading policy. Class loaders are first-
class obj e cts. Programmers have complete control of
dynamic cla ss loading. A user-defined class loader can ,
for example, specify the remote location from which
To appear in the 13t h Annual ACM SIGPLAN Conference
on Object-Oriented Programming Systems, Languages,
and Applications (OOPSLA’98), Vancouver, BC, Canada,
October, 1998 .
the classes are loaded, or assign appropriate security
attributes to classes loaded from a particular source.
4. Multiple namespaces. Class loaders provide separate
namespaces for different software components. For
example, the Hotjava
TM
browser loads applets from
different sources into separate class loaders. These
applets may contain c lasses of the same name, but the
classes are treated as distinct types by the Java virtual
machine.
In contrast, existing d ynamic linking mechan isms do
not support all of these features. Although most operating
systems support some form of dyna mic linked libraries, su ch
mechanis ms are targeted toward C/C++ code, and are not
type-safe. Dynamic languages such as Lisp [13], Smalltal k
[6], and Self [21] achieve type safety through additional
run-time checks, not link-time checks.
The main contribution of this paper is to provide the
first in-depth description of class loaders, a novel c oncept
introduced by the Java platform. Class l oaders existed in
the first version of the Java Development Kit (JDK 1 .0). T he
original purpose was to enable applet c lass loading in the
Hotjava browser. Since that time, the use of class loaders
has been extended to handle a wider range of software
components such as server-side components (servlets) [11],
extensions [10] to the Java platform, and JavaBeans [8]
components. Despite the increasingly important role of class
loaders, the u nderlying mechanism has not been adequately
described in the literature.
A further contribution of this paper is to present a
solution to the long-standing type safety problem [20] with
class loaders. Early ver sions (1.0 and 1.1) of the JDK
contained a serious flaw in class loader implementation.
Improperly written class loaders could defeat the type safety
guarantee of the Java virtual machine . Note that the type
safety problem did not impose any immediate security risks,
because untrusted code (such as a d ownloaded applet) was
not allowed to create c lass loaders. Nonetheless, application
programmers who had the need to write custom class loaders
could compromise type safety inad ver tently. Although the
issue had been known for some time, it remained an open
problem in the research community whether a satisfactory
solution exists. For example, earlier discussions centered
around whether the lack of type safety was a fundamental