Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1999-11-02
2003-10-14
Robinson, Greta (Department: 2177)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000
Reexamination Certificate
active
06633892
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field
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 these classes are compiled into Java bytecodes, these 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 alsospecify Java archive files (.jar files) from which classes can be loaded. Unfortunately, this Java programing 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 is 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 archiving 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, the 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 would 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 difficulty 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 a .jar archive file which resides in different directories. 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 archive file 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 being called from.
SUMMARY OF THE INVENTION
According to an aspect of the invention, there is provided an archiving tool computer product, said tool comprising an input means for receiving into a memory a byte representation of the file from an archive file and an entry name of the file from the archive file; and means for creating a meta-object for the file including the. byte representation of the file and the entry name of the file. The archiving tool computer product may further comprise archiving means for storing the byte. representation of the file from the meta-object for the file to an output archive file using said entry name from the meta-object for the file. Additionally, the meta object for the file may further include a file name designating the location of the file represented by the meta-object. The entry name may correspond to the name of the file in the archive file including any directory information. And, the archiving tool computer tool product may further comprise means for customizing the entry name of the file.
According to another aspect of the invention, there is provided a method for archiving comprising the steps of receiving into a memory a byte representation of a file from an archive file and an entry name of the file from the archive file; and creating a meta-object for the file including the byte representation of the file and the entry name of the file. The method may further comprise the step of storing the byte representation of the file from the meta-object for the file to an output archive file using said entry name from the meta-object for the file. Additionally, the meta object for the file may further include a file name designating the location of the file represented by the meta-object. The entry name may correspond to the name of the file in the archive file including any directory information. And, the method may further comprise selectively customizing the entry name of the file.
According to another aspect of the invention, a method for creating an archive file, said method comprising the steps of reading a meta-object from a memory, said meta-object representing a file; converting said meta-object for the file for storage in said archive file; and storing the file represented by said converted meta-objects in said archive file.
There is also provided a program storage device readable by a data processing system, tangibly embodying a program of instructions, executable by said data processing system to perform the above method steps.
In another aspect of the invention, a method of deploying files, s
Chan Victor S.
Chiang Shirley S.
Stokes David K.
Theivendra Leonard W.
Dodds Harold E.
International Business Machines - Corporation
Robinson Greta
Schecter, Esq. Manny W.
Scully Scott Murphy & Presser
LandOfFree
Archiving tool does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Archiving tool, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Archiving tool will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3130812