Data processing: software development – installation – and managem – Software program development tool – Linking
Reexamination Certificate
1999-11-29
2002-10-22
Dam, Tuan Q. (Department: 2124)
Data processing: software development, installation, and managem
Software program development tool
Linking
C717S139000
Reexamination Certificate
active
06470494
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field
The present invention relates to class loaders in software environments and the dynamic loading of classes during the execution of program files.
2. Prior Art
Currently, in typical Sun Microsystems, Inc.'s Java™ software programming language environments, the execution of Java programs first requires that the source code for these programs be compiled into Java bytecodes, which are instructions for a virtual computer, called the Java virtual machine (JVM). A JVM may be implemented either in software (as a JVM interpreter) or in hardware (as a JVM chip).
Java program source code typically consists of a set of classes stored in a series of class files. After the classes are compiled into lava bytecodes are then typically loaded into memory by a class loader for interpretation by a JVM interpreter before the associated program is executed. Class loading can also occur when a Java program dynamically attempts to load another class at run time.
In current Java programming environments (e.g. the Java Development Kit (JDK) produced by Sun Microsystems, Inc.), the default class loader makes use of an environment-variable which stores directory information on where the class loader should look for class files on a secondary storage device. For instance, when programming in Java using the JDK, an environment variable called CLASSPATH, is used for this purpose. In addition to directories, the CLASSPATH environment variable can also specify Java archive files (.jar files) from which classes can be loaded. Unfortunately, this Java programming environment does not allow for the modification of the CLASSPATH environment variable in a JVM during the execution of a program. As a result, certain directories and jar files cannot be dynamically specified at run time. Thus, the programmer is required to specify the location of all classes forming part of a program to be executed prior to run time, even in cases where it may not be feasible or possible to do so.
For example, in some cases, the location of certain classes which require loading is known only at run time. This situation may arise when an application to create a .jar file s being executed, and the classes to be included in the jar file need to be determined during execution of the application. Alternatively, it may be impossible at run time to obtain or specify the location of classes used by other classes or applications which reside on a remote machine.
Furthermore, standard tools for creating .jar files in Java programming environments cause the entry name of each class file or other file in a Java archive to reflect where the file is physically located in a file system, as well as where the archiving tool is being called from.
For example, when using the JDK, if files A.class and B.class in the package com.ibm.ejs were to be placed in a .jar archive file with entry names com/ibm/ejs/A.class and com/ibm/ejs/B. class respectively, a standard Jar archiving tool might be called using the.command:
jar-cvf out.jar com/ibm/ejs/A.class com/ibm/ejs/B.class
if the Jar archivig tool was called from the same directory which stores the class files for the package com.ibm.ejs. If the Jar archiving tool were to be called from a different directory, the input parameters in the above command would have to be changed to reflect the location from which the Jar archiving tool was being called. For example, if the Jar archiving tool is called from the directory ‘work’, the Jar archiving tool would be called using the command:
jar-cvf out.jar work/com/ibm/ejs/A.class work/com/ibm/ejs/B.class
and as a result, te entry name of the classes in the .jar archive file will also be modified to reflect the location from which the Jar archiving tool was being called. Therefore, if the Jar archiving tool is called from the directory ‘work’, the entry name of A.class and B.class stored in the .jar archive file wold be work/com/ibm/ejs/A.class and work/com/ibm/ejs/B.class respectively. A JVM which is looking for a particular class in the .jar archive file when executing a program, may have difficultly locating the file in a situation where the entry name has been so modified.
One possible solution to this problem would be to change the working directory in the current programming environment so that the Jar archiving tool is always called from the directory in which a particular file to be added to a .jar archive file resides. This may require the working directory to be changed several times if there are numerous files being added to .jar archive file which reside in different directions. In some cases the files to be added to a .jar archive file may even reside on a remote system. Since the working directory for a JVM cannot be dynamically changed at run time, and since causing the Jar archiving tool to be called from a different directory is neither always feasible nor always possible, standard tools in the JDK do not afford a flexible solution to this problem.
It will be appreciated by those skilled in the art, that a programming environment which allows for the loading of classes without the need for specifying a path prior to the execution of a program would allow for greater flexibility in the use and design of such programs.
Furthermore, with respect to creating jar files, flexibility in the use and design of such programs would be further enhanced if the entry name of a class file or other file to be placed in a jar chive could be assigned a name that is independent of where the file is physically located on a file system and of where a Jar archiving tool may be called from.
SUMMARY OF THE INVENTION
According to an aspect of the invention, there is provided a dynamic class loader computer product for providing a class in executable form in response to a request for said class, said dynamic class loader computer product comprising a first structure comprising pointers for byte representations of classes in a memory; means for checking if a pointer for said class is provided in the first structure; conversion means for converting said class into executable form using the byte representation of said class pointed to by the pointer; and means for providing said class so converted in response to the request. The dynamic class loader computer product may further comprise an input means for receiving into the memory the byte representation of said class and a name of said class and for adding a pointer to the first structure for the byte representation of said class. Further, the dynamic class loader computer product may comprise second structure containing a pointer to said class in executable form in memory. Additionally, the dynamic class loader computer product may comprise means for checking if a pointer for said class is provided in the second structure and if provided, instead of providing said class so converted, providing said class in executable form in memory pointed to by that pointer in response to the request. The dynamic class loader computer product may further comprise means for adding a pointer to the second structure for said class in executable form in memory. And, there is provided a dynamic class loader computer product wherein said dynamic class loader computer product provides a means to invoke a different class loader computer product should said dynamic class loader product be unable to locate a pointer for said class in response to the request. Also, said first structure may be a first hash table, said second structure may be a second hash table and the classes may be Java class files.
In accordance with another aspect of the invention, there is provided a method for loading a class in executable form in response to a request for said class comprising the steps of providing a first structure comprising pointers for byte representations of classes in a memory; checking if a pointer for said class is provided in the first structure; converting said class into executable form using the byte representation of said class pointed to by the pointer; and providing said class so converted in re
Chan Victor S.
Chiang Shirley S.
Stokes David K.
Theivendra Leonard W.
Chavis John Q.
Dam Tuan Q.
Schecter, Esq. Manny W.
Scully Scott Murphy & Presser
LandOfFree
Class loader does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Class loader, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Class loader will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2988949