Dynamic Class Loading in the Java Virtual Machine
5星 · 超过95%的资源 需积分: 9 159 浏览量
2008-03-05
09:33:33
上传
评论 1
收藏 1009KB PDF 举报 
Dynamic Class Loading in the JavaTM Virtual Machine
Sheng Liang
Gilad Bracha
Sun Microsystems Inc.
901 San Antonio Road, CUPO2-302
Palo Alto, CA 94303
{sheng.liang,gilad.bracha}@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-q? linkage, user-defined extensibility,
and
multiple
communicating namespaces.
We present the notion of class loaders and demonstrate
some of their interesting uses. 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 an 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 nmtime. An example of a component is an
applet that is
downloaded into a web browser.
While many other systems 1161 1131 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-s@ linkage.
Dynamic class loading must not
violate the type safety of the Java virtual machine.
Dynamic loading must not require additional run-time
checks in order to guarantee type safety. Additional
link-time checks are acceptable, because these checks
are performed only once.
3. User-denable class loading policy.
Class loaders are first-
class objects. Programmers have complete control of
dynamic class loading. A user-defined class loader can,
Permossmn to make dlgital or hard copses 01 all or parf of this work for
personal or classroom use IS granted wthout lee prouded that
copies are not made or distributed for profIt or commercial advan-
tage and that coptes bear this notIce and the full cltatlo” 0” the first page
lo copy otherwise, to republtsh. to post on Servers or to
redlstnbute to hsts. requres pnor spec111c permlss~o” and/or a fee
OOPSLA ‘98 lo/98 Vancouver, B.C.
B 1998 ACM 1.58113.005.9/98/0010...55.00
4.
for example, specify the remote location from which
the classes are loaded, or assign appropriate security
attributes to classes loaded from a particular source.
Multiple namespaces.
Class loaders provide separate
namespaces for different software components. For
example, the HotjavaTM browser loads applets from
different sources into separate class loaders. These
applets may contain classes of the same name, but the
classes are treated as distinct types by the Java virtual
machine.
In contrast, existing dynamic linking mechanisms do
not support all of these features. Although most operating
systems support some form of dynamic linked libraries, such
mechanisms are targeted toward C/C++ code, and are not
type-safe. Dynamic languages such as Lisp 1131, Smalltalk
[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 concept
introduced by the Java platform. Class loaders existed in
the first version of the Java Development Kit (JDK 1.0). The
original purpose was to enable applet class 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) [ll],
extensions [lo] to the Java platform, and JavaBeans [8]
components. Despite the increasingly important role of class
loaders, the underlying 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 versions (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 downloaded applet) was
not allowed to create class loaders. Nonetheless, application
programmers who had the need to write custom class loaders
could compromise type safety inadvertently. 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
36
- 1
- 2
前往页