Independent class loader for dynamic class loading

Details Independent class loader for dynamic class loading Independent class loader for dynamic class loading

2001-06-01

2004-06-08

Metjahic, Safet (Department: 2171)

Data processing: database and file management or data structures

Database design

Data structure types

C709S241000

Reexamination Certificate

active

06748396

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to computer programming, and deals more particularly with methods, systems, and computer program products for improving the manner in which classes are dynamically loaded during program execution.
2. Description of the Related Art
There are a number of approaches to dynamically loading interdependent components of executable code (such as plug-ins, bundles, etc.) in modern programming languages. In the Java™ programming language, classes are dynamically loaded using a class loader as an application program executes. (“Java” is a trademark of Sun Microsystems, Inc.) The class loader is responsible for searching for a particular class, and making that class available to the run-time system if found. Once loaded, each Java class object retains a reference to the class loader with which it was loaded. Java class loading is based on a delegation model, wherein a class loader first delegates the class loading responsibility to its immediate parent class loader. If neither that parent class loader nor any of its ancestors, in turn, are able to locate the class, then the initial class loader is used for the loading operation. Inheritance in the class loader chain is under control of the programmer, who may specify an explicit parent relationship when creating a new class loader. Each time a class loader is created, it is associated with one or more locations (such as file tree structures, archives, etc.) that it will be searching for classes.
FIGS. 1A-1C
illustrate this prior art dynamic class loading technique with a simple example. Suppose that the following Java code is encountered while running code in the class named “Foo”:
new Bar( )
That is, a new instance of the class named “Bar” is to be instantiated. Using standard Java class loading, it is first necessary to determine the class loader used to load Foo. The Java code element
100
in
FIG. 1A
illustrates syntax which may be used for this purpose, wherein a variable “C” is assigned to the result of invoking the “getClassLoader” method on the Foo class. The next step is to use that class loader to load the class Bar. Syntax which may be used for this purpose is shown at
105
, wherein the method “loadClass” on class loader C is invoked with “Bar” as a parameter. The flowchart in
FIG. 1C
illustrates the logic with which this loadClass method operates. First, a check is made to see if Bar is already in this loader's cache (Block
140
). If so, then it is riot necessary to reload the class, and the located value (i.e. the class) is returned (Block
165
). Otherwise, a recursive process begins (Block
145
) where the parent of this class loader is asked to load the requested class.
For a class to be successfully loaded, the class loader used (or one of its ancestors) must be able to load all of the class' superclasses and interfaces. As a result, if a superclass is loaded by a different loader, that loader must be a parent somewhere in the ancestor chain of the loader used to load the class (Bar, in this example). For example, with reference to the class loader hierarchy
110
in
FIG. 1B
, suppose the class loader responsible for loading class Foo is class loader “CL3”
125
. This class loader therefore requests its parent class loader “CL2”
120
to load class Bar, and so on until either finding an already-loaded Bar or until no more ancestors remain to be checked. In the former case, the test in Block
150
has a positive result, and the located class is returned by Block
165
. In the latter case, the test in Block
150
has a negative result and control reaches Block
155
. At that point, the class path
120
for class Bar is determined (using the CLASSPATH variable), and a check is made (Block
160
) to see if Bar can be located using that class path. If so, then the located class is loaded (BLOCK
170
) and immediately initialized; otherwise, an error is returned (Block
175
). After the class is loaded in Block
170
, control returns to Block
165
to return the loaded class to the caller. This dynamic loading technique is well known in the computer programming art, and code to implement the class loader process is commonly provided as part of Java development toolkits.
There are a number of problems with this prior art class loading approach, however. Because the delegation model is linked to Java's single inheritance class structure, a class loader parent chain must be able to load a complete Java type graph. This necessarily limits subsystems to only one prerequisite, and that prerequisite (and its ancestry) must be able to supply all of the subsystem's ancestor classes: a complex composition of prerequisite components cannot be supported under this approach. In other words, the Java programmer needs to make sure that all type relationships implied in the class implementation (including extended classes, implemented interfaces, declared data member types, argument types of methods, return types of methods, etc.) can be loaded by its single loader chain. When dealing with complex functional relationships, the programmer typically addresses this problem by adding all the required archives, or “jar” files, on a single long class path. This is a less-than-optimal solution. Furthermore, components such as plug-ins are relatively “heavyweight” entities in that they require a considerable amount of resources (i.e. storage) to be allocated, take time to be initialized, and will often trigger the loading of many classes once initialized (which consumes more resources and takes additional time). This approach results in an inefficient use of resources in many cases, and increases the start-up time and the memory footprint of the program in which the plug-in is contained. For example, it may happen that some classes are not actually accessed until a relatively long time after activating the plug-in whose initialization triggered loading of the class, and some may never be accessed. These inefficiencies become especially significant in resource-constrained systems.
Other approaches to dynamic class loading, such as OSGi (“Open Services Gateway Initiative”) bundles, use an independent class loader for each component, rather than using the delegation model which has been described with reference to
FIGS. 1A-1C
. However, OSGi bundles do not address the limitations of dynamic class loaders which have been discussed. OSGi bundles continue to rely on parent relationships during loading, and initialize upon start-up as well. (The term “OSGi bundles” refers to components which adhere to the OSGi Service Gateway Specification. OSGi bundles are archive files containing class files and resources. A bundle's manifest file identifies the bundle's contents and also the packages and services which are imported and exported by that bundle. More information on this specification may be found on the Internet at location http://www.osgi.org/about/spec1.html.)
Accordingly, what is needed is an improved technique for dynamically loading independent components (that is, those components whose classes are not necessarily located within a single functional dependence hierarchy).
SUMMARY OF THE INVENTION
An object of the present invention is to provide an improved technique for dynamically loading independent code components.
Yet another object of the present invention is to provide an improved technique for loading components which are not located within a single functional dependence hierarchy chain.
Another object of the present invention is to provide a technique for dynamically loading components which supports complex prerequisites.
Still another object of the present invention is to provide a technique for dynamically loading components which allows explicitly specifying one or more prerequisite components.
A further object of the present invention is to provide a technique for dynamically loading components which delays initialization and loading of components until the component is needed.
Other objects and advantages of the pre

Affiliated with

Also associated with

Rating

Independent class loader for dynamic class loading does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Independent class loader for dynamic class loading, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Independent class loader for dynamic class loading will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3321224