Electrical computers and digital processing systems: support – Digital data processing system initialization or configuration – Loading initialization program
Reexamination Certificate
2000-01-27
2002-05-07
Butler, Dennis M. (Department: 2182)
Electrical computers and digital processing systems: support
Digital data processing system initialization or configuration
Loading initialization program
C713S152000
Reexamination Certificate
active
06385722
ABSTRACT:
BACKGROUND OF THE INVENTION
A. Field of the Invention
This invention relates to systems for limiting access to parts of shared software libraries and, more particularly, to systems for limiting access to object class definition files within shared libraries using class loaders.
B. Description of the Related Art
Software vendors typically ship their products as a set of shared libraries, such as libraries written in the Java™ object-oriented programming language and packaged as a conventional shared library file called a JAR file. In this manner, program files stored within these libraries can be easily and efficiently shared and used by any program module that is part of the vendor's product.
Shared libraries are often used to maintain class definitions when the vendor's product is written using object-oriented programming. In an object-oriented programming environment, an object generally encapsulates data members and function members (or methods) that manipulate the data member. An object is an instance of a class, which defines various data members and methods shared by objects of the same class. Thus, shared libraries can be used to define each type of object used in the vendor's product.
It is important that a user be able to access the parts of shared libraries that are meant to be shared. This is how its contents (generally referred to as program files) are meant to be used in such a library implementation. However, not all of the contents are meant to be used externally to the shared library. There are class definitions and objects that can be accessed by any code that uses the shared library, even though these class definitions and objects are meant to be only used internally in the library implementation. As a result, one of the problems faced by software vendors using shared libraries is limiting access to those parts of shared libraries that are not meant to be shared externally to the library implementation. For example, in a Java™ library packaged into a JAR file, a package is declared to be public and can then be accessed by any code that uses the Java™ library despite the fact that the Java™ package is meant to be only used internally to the library.
Aside from the basic problem of providing an external process with unauthorized access to these parts of the shared library, other problems may occur as a result of doing so. For example, namespace problems may occur when externally using parts of a shared library that are supposed to be only used internal to the library. The software vendor that created the shared library may use specific names or a naming convention for parts of the shared library without regard to namespace collisions external to the shared library. However, when an external process accesses a package meant to be strictly internal to the library, the name for the package may conflict with the name of another package or object already used by the external process. In such a situation, there may be a duplication of class definitions for a given package name leading to problems on how to resolve what functionality is associated with the named packages or objects.
The introduction of sealing in the Java™ programming language has improved the situation by allowing some instances of this problem to be detected and an error raised. However, simply raising an error at run-time and requiring the end user to take appropriate action to fix the problem is not as desirable as having the program work as intended. Also, sealing will not generally help in the important case of wanting to ship an application or applet bundled with a particular version of some extension. If some different version of that extension is already installed on an end user's computer, the installed one takes precedence over the bundled one.
Accordingly, there is a need for a system that permits access to certain parts of a shared library while limiting access to other parts of the shared library.
SUMMARY OF THE INVENTION
Methods, systems, and articles of manufacture consistent with the present invention overcome the shortcomings of existing systems by using a class loader to limit access to parts of a shared library, such as a JAR file. The class loader generates an interface between external processes seeking to access a program file in the library and the files in the library itself. Methods, systems, and articles of manufacture consistent with the present invention, as embodied and broadly described herein, load a program file from a shared software library. Typically the program file is a class definition loaded by a class loader. Next, an interface to the loaded program file is generated. The interface, preferably an interface object, has a status indicator as to whether the program file can be exported. The status indicator, preferably determined by executing a status method that is part of the preferred interface object, is used to determine if the program file can be exported from the shared library. The status method is typically created by reading an attribute within the shared library that indicates if the program file can be exported. If the program file cannot be exported based on the status indicator, access to the program file is limited. On the other hand, if the status indicator shows the program file can be exported, the program file is returned to a requesting process.
In accordance with another aspect of the present invention, methods, systems, and articles of manufacture, as embodied and broadly described herein, describe a system for limiting access to an object class definition in a shared library. The system has a memory storage device that maintains the shared library and a class loader. The system also includes a processor coupled to the memory storage device. The processor is operative to load the object class definition from the shared library on the memory storage device using the class loader. Once the appropriate object class definition has been located within the shared library and loaded, the processor is further operative to create an instance of an interface object in the memory storage device typically by calling a package method within the class loader. The interface object is associated with the object class definition and includes a status method created by the processor as part of the interface object in the memory storage device. The status method defines a function that designates if the object class definition is accessible by an external process running on the processor. The processor is also operative to call the status method to determine if the object class definition is designated to be accessible to the external process. Finally, the processor is capable of limiting access to the object class definition if the executed status method indicates the object class definition is not designated to be accessible to the external process.
In accordance with yet another aspect of the present invention, methods, systems, and articles of manufacture, as embodied and broadly described herein, describe a computer-readable medium, which contains instructions for limiting access to an object class definition within a shared software library. When the instructions are executed, the object class definition is loaded from the shared software library using a class loader. Next, an instance of an interface object associated with the object class definition is created by the class loader along with a status method related to the interface object. Typically, another method within the class loader is called to created the instance of the interface object. The status method indicates if the object class definition is designated to be accessible by an external process. The status method is called to determine if the object class definition is designated to be accessible to the external process. Finally, access to the object class definition is limited or denied if the status method indicates the object class definition is not designated to be accessible to the external process.
REFERENCES:
patent: 5359721 (1994-10-01), Kempf et al.
patent: 56
Connelly David W.
Liang Sheng
Renaud Benjamin
Butler Dennis M.
Finnegan Henderson Farabow Garrett & Dunner LLP
Sun Microsystems Inc.
LandOfFree
Method, system, and article of manufacture for limiting... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method, system, and article of manufacture for limiting..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method, system, and article of manufacture for limiting... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2818930