1. Field of the Invention
This invention generally relates to a data processing system and, more particularly, to a method and system in an object-oriented data processing system for generating proxy classes at runtime that implement a list of interfaces specified at runtime.
2. Related Art
Many computing systems use object-oriented programming to better accommodate the increasing complexity and cost of large computer programs. Object-orient programming languages have grown to be widely used due to their programming power and efficiency. In an object-oriented computing system, source code written in an object-oriented programming language, such as the Java™ programming language, typically contains a number of “classes,” such as Java classes. A class is a template for creating objects that are “instances” of the class and are created from the template. A class contains both data members that store data and function members (or “methods”) that act upon the data. Consequently, the class of an object defines its data and behavior, and the methods (function members) are typically used to both get and set the values for the data members in the class.
Additionally, object-oriented programming languages such as the Java programming language utilize “interfaces,” which are simply lists of methods. An interface is similar to a class but typically only has declarations of its methods and typically does not provide implementation of those methods. An interface specifies methods supported by classes that implement the interface and declares what those methods should do. Classes, instances, interfaces and other aspects of object-oriented programming languages are discussed in detail in “The Java Programming Language”, 2nd Ed., Ken Arnold, James Gosling, Addison-Wesley, 1998, which is incorporated herein by reference. For further description of the Java language, refer to “The Java Language Specification,” James Gosling, Bill Joy, Guy Steele, Addison-Wesley, 1996, which is also incorporated herein by reference.
When the source code for classes, interfaces and other aspects of an object-oriented programming language are created, they are usually written by a user and then compiled by a compiler on a computer so that the computer may run the source code. The source code is written and then compiled at a stage referred to as “compile-time.” After the source code has been built and compiled, a computer system may then execute the source code at “runtime.”
Since a class typically has to be built offline and then compiled, the interfaces implemented by that class must typically be known while the class is being built before runtime. Conventionally, to implement an interface by a class, the methods of the interface are determined during source code development before compile-time. For example, section 4.5 of Arnold and Gosling's “The Java Programming Language” describes an approach called “forwarding” to make a class use a second class for the implementation of one of its interfaces. This approach is simply to define every single method of the interface in the first class to delegate to the corresponding method in the second class. However, section 4.7 characterizes this approach as “tedious to implement and error-prone,” which is further demonstrated by the fact that compile-time tools have been developed to automate the process of generating these forwarding methods.
Sometimes the interfaces that a user would like to implement may not be known or may be changing during the runtime of the program. As a result, it would be desirable to have a method and system that avoids the need to generate before runtime a class that implements a list of interfaces and avoids the need to write and compile code for each method of an interface being implemented.
Conventionally, to implement a single functionality on multiple interfaces of varying types, code needs to be created for each interface to carry out the functionality. It would also be desirable to not require the writing of specialized code for each one of multiple types of interfaces to facilitate a single functionality.
Methods and systems consistent with the present invention provide a proxy class that is dynamically generated at runtime and that implements a list of interfaces specified at runtime. Method invocations on an instance of the proxy class are encoded and dispatched uniformly to another object that handles the method invocation. In accordance with the present invention, the proxy class generated at runtime does not require the implemented interfaces and their methods to be known before runtime, i.e., during development or at compile-time. Since no pre-generation of the class before runtime is required, the interfaces desired to be used may change during runtime before the creation of the proxy class. Additionally, the proxy class may provide uniform implementation of multiple types of interfaces without requiring specialized code for each one.
In accordance with methods and systems consistent with the present invention, a client may invoke a method of an interface implemented by the proxy class to an instance of the proxy class, and the proxy class instance encodes and dispatches the method to an invocation handler object associated with the proxy class instance that processes the method invocation and returns the result to the client via the proxy class instance.
In accordance with methods and systems consistent with the present invention, a method in a data-processing system generates at runtime a proxy class that implements one or more interfaces specified at runtime having methods, and creates an instance of the proxy class. Further, the proxy class instance receives a request to process a method of an interface, and dispatches the request to an invocation handler object that processes the request for the method.
In an object-oriented data processing system, methods and systems consistent with the present invention provide a proxy class, dynamically generated at runtime, that implements a list of interfaces specified at runtime. A method invocation through an interface on an instance of the class is encoded and dispatched uniformly regardless of the type of interface to an invocation handler object that performs the invocation of the requested method. Thus, in this manner, multiple interfaces may share the same code, which reduces wasteful duplication.
The dynamic generation of the proxy class at runtime and the specification at runtime of the list of interfaces and their methods supported by the proxy class allow the interfaces to be chosen after compile-time, but before the generation of the proxy class. Since the proxy class does not need to be created before compile time, the list of interfaces implemented by the proxy class does not need to be known at the time the source code is written, i.e., during development. Thus, a client that uses the proxy class to invoke methods on one or more interfaces is independent of the interfaces, so if different interfaces are selected, the client does not need to rebuild the proxy class. Moreover, as new interfaces are become available, the client may utilize them without modification.
The proxy class provides uniform access to the methods of the multiple types of interfaces implemented by the proxy class without regard to the type. If a client wishes to make a method invocation for a method of an interface implemented by the proxy class, the client may send the method invocation to an instance of the proxy class. The proxy class instance automatically encodes and dispatches a method invocation of a method on an interface implemented by the proxy class instance to an invocation handler object that automatically handles the request and returns the result. The invocation handler returns the result to the proxy class instance and then back to the client that made the original method invocation request.
The invocation handler is an object created by the client that is associated with the proxy class instance and processes the request received from the proxy class instance. The invocation handler is created to be application-specific and can be formed in a wide variety of ways depending on the application desired by the client.
For an example use of a dynamic proxy class, consider the following. A client may want to register to receive notification of events from a number of event generators, such as a windows manager and a device driver. However, each event generator typically may use a different interface and the programmer may not know at compile time what the interfaces may contain or even which interfaces the client may need at runtime. The dynamic proxy class in accordance with methods and systems consistent with the present invention solves this problem.
In using the dynamic proxy class, the client, at runtime, specifies the interfaces in which it is interested. That is, the client may receive an indication through the user interface or some other runtime mechanism which causes it to want to utilize a number of interfaces. So, the client invokes, for example, a Java Class Library (described below) call using a name or other identifier to obtain a class object representative of each desired interface. Then, the client utilizes another call to create a dynamic proxy class, which supports the interfaces. Lastly, the client instantiates the proxy class by providing it an invocation handler. Once the proxy class is instantiated, the instance of the proxy class implements the interfaces and can be registered, for example, with each of the event generators. Since the proxy object supports each of the event generator interfaces, each event generator recognizes the proxy object and can invoke the methods on the interface for that event generator. Furthermore, for every method invoked, the same invocation handler is invoked, thus needless duplication of code is prevented. This invocation handler performs common functionality for each of the methods. For instance, for each method invoked, representing the occurrence of an event, the invocation handler may log the event into a file. In this manner, the client need not know of the interfaces before runtime and can have common functionality used for a number of interfaces.
Although the example is described as using the proxy class by an entity other than the creator, one skilled in the art will appreciate that it may be beneficial for a client to both create and use the proxy class.
As another example, dynamic proxy classes may be applied to remote method invocations (“RMI”) that allow objects executing on one computer to invoke method of an object on another computer. If a proxy class is to be used for the purpose of RMI on a remote server, the interfaces implemented by the dynamic proxy class might be a list of the methods available on the remote server, and the invocation handler might perform the function of forwarding the call to the location of a remote object. In this manner, the dynamic proxy class can be created using interface specifications received from a remote server at runtime, and the interface specifications need not be known beforehand at compile-time. In conventional systems, the proxy class is typically built offline, compiled and then downloaded before runtime, thereby reducing runtime flexibility.
Main memory 104 also contains a virtual machine 118 (“VM”), such as a Java VM, which acts as an abstract computing machine, receiving instructions from programs in the form of byte codes and interpreting these byte codes by dynamically converting them into a form for execution, such as object code, and executing them. Java virtual machines are described in detail in “The Java Virtual Machine Specification,” Lindholm and Yellin, Addison-Wesley, 1997, which is incorporated herein by reference. The memory also contains a runtime system, such as a Java Runtime Environment (“JRE”) 120, which further contains class file libraries 124 which define classes used by programs running on the JRE. The class file libraries 124 contain definitions for “Class.forName” and “getProxyClass” methods which will be discussed below. The Class.forName function and other aspects of Java class libraries are described in detail in “The Java Class Libraries: An Annotated Reference,” Chan and Lee, Addison-Wesley, 1997, which is incorporated herein by reference. Although Java components are discussed, methods and systems consistent with the present invention may utilize other types of components.
The main memory 104 also contains an invocation handler 122 that is an object created by the client 116. The invocation handler 122 is created to be application-specific and may vary depending on the purpose of the proxy class 202. For example, in the event listener scenario, the invocation handler 122 performs the function of logging events to a file. As stated, the client 116 creates the proxy class instance 204 by passing the invocation handler 122 as an argument and thus is associated with the invocation handler 122 upon creation. When the proxy class instance 204 receives a method invocation request from a client 116, the proxy class instance 204 encodes and dispatches the method request to the invocation handler 122. The invocation handler 122 processes method invocations made to the proxy class instance 204 and returns a result to the proxy class instance to be returned to the client 116.
Although aspects of the present invention are described as being stored in memory or a VM, one skilled in the art will appreciate that these aspects can also be stored on or read from other types of computer-readable media, such as secondary storage devices, like hard disks, floppy disks, or CD-ROM; a carrier wave from a network, such as the Internet; or other forms of RAM or ROM either currently known or later developed. Sun, Sun Microsystems, the Sun logo, Java™, and Java™-based trademarks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.
In one implementation consistent with the present invention, once the interfaces 206 and 208 to be implemented are determined, using the names of the interfaces, a client 116 may call a function such as the Class.forName function to obtain the “Class Objects” of the desired interfaces (step 304). The Class Objects are representations of the interfaces 206 and 208 and are used as the arguments for the getProxyClass method. Given the names of the desired interfaces 206 and 208, the Class.forName method returns the Class Objects of the required interfaces (step 306).
Once the client 116 has the Class Objects of the desired interfaces 206 and 208, it may generate a proxy class 202 for the interfaces by calling the getProxyClass method using the interface's Class Objects as arguments (step 308). The getProxyClass method returns a proxy class 202 that implements the interfaces 206 and 208 (step 310). To this end, the getProxyClass method generates custom code for each method of the interfaces that will encode and dispatch a method invocation to the invocation handler 122 including the arguments. This process is described below in further detail in FIG. 4. The client also creates the invocation handler 122 that will carry out the desired functionality of a call to an instance 204 of the proxy class 202 (step 312). The client then creates a proxy class instance 204 by calling the constructor of the proxy class 202 with the invocation handler 122 as an argument (step 314).
As a result, methods and systems in accordance with the present invention allow a proxy class to be generated at runtime that can implement interfaces specified at runtime thereby avoiding a need for pre-generation of the proxy class and predetermination of the interfaces before runtime. They also facilitate the processing of method invocations to a single object that uniformly handles method invocations of varying types of multiple interfaces.
The following code contains portions of commented code that outlines a class that may be used for the creation of a proxy class written in the Java programming language. Proxy classes, as well as instances of them, may be created using the static methods of the this class (note that the javadoc in the code presented here is not specification-complete):
package java.lang.reflect;
The foregoing description of an implementation of the invention has been presented for purposes of illustration and description. It is not exhaustive and does not limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teaching or may be acquired from practicing of the invention. The scope of the invention is defined by the claims and their equivalents.
Number | Name | Date | Kind |
---|---|---|---|
4491946 | Kryskow, Jr. et al. | Jan 1985 | A |
4713806 | Oberlander et al. | Dec 1987 | A |
4809160 | Mahon et al. | Feb 1989 | A |
4823122 | Mann et al. | Apr 1989 | A |
4939638 | Stephenson et al. | Jul 1990 | A |
4956773 | Saito et al. | Sep 1990 | A |
5088036 | Ellis et al. | Feb 1992 | A |
5109486 | Seymour | Apr 1992 | A |
5187787 | Skeen et al. | Feb 1993 | A |
5218699 | Brandle et al. | Jun 1993 | A |
5257369 | Skeen et al. | Oct 1993 | A |
5293614 | Ferguson et al. | Mar 1994 | A |
5297283 | Kelly, Jr. et al. | Mar 1994 | A |
5311591 | Fischer | May 1994 | A |
5339435 | Lubkin et al. | Aug 1994 | A |
5386568 | Wold et al. | Jan 1995 | A |
5390328 | Frey et al. | Feb 1995 | A |
5423042 | Jalili et al. | Jun 1995 | A |
5440744 | Jacobson et al. | Aug 1995 | A |
5448740 | Kiri et al. | Sep 1995 | A |
5455952 | Gjovaag | Oct 1995 | A |
5471629 | Risch | Nov 1995 | A |
5475792 | Stanford et al. | Dec 1995 | A |
5475817 | Waldo et al. | Dec 1995 | A |
5481721 | Serlet et al. | Jan 1996 | A |
5504921 | Dev et al. | Apr 1996 | A |
5511197 | Hill et al. | Apr 1996 | A |
5524244 | Robinson et al. | Jun 1996 | A |
5553282 | Parrish et al. | Sep 1996 | A |
5555367 | Premerlani et al. | Sep 1996 | A |
5557798 | Skeen et al. | Sep 1996 | A |
5560003 | Nilsen et al. | Sep 1996 | A |
5561785 | Blandy et al. | Oct 1996 | A |
5577231 | Scalzi et al. | Nov 1996 | A |
5603031 | White et al. | Feb 1997 | A |
5617537 | Yamada et al. | Apr 1997 | A |
5628005 | Hurvig | May 1997 | A |
5640564 | Hamilton et al. | Jun 1997 | A |
5644768 | Periwal et al. | Jul 1997 | A |
5652888 | Burgess | Jul 1997 | A |
5655148 | Richman et al. | Aug 1997 | A |
5659751 | Heninger | Aug 1997 | A |
5671225 | Hooper et al. | Sep 1997 | A |
5675796 | Hodges et al. | Oct 1997 | A |
5680573 | Rubin et al. | Oct 1997 | A |
5680617 | Gough et al. | Oct 1997 | A |
5684955 | Meyer et al. | Nov 1997 | A |
5689709 | Corbett et al. | Nov 1997 | A |
5706435 | Barbara et al. | Jan 1998 | A |
5724588 | Hill et al. | Mar 1998 | A |
5727145 | Nessett et al. | Mar 1998 | A |
5737607 | Hamilton et al. | Apr 1998 | A |
5745678 | Herzberg et al. | Apr 1998 | A |
5745695 | Gilchrist et al. | Apr 1998 | A |
5745703 | Cejtin et al. | Apr 1998 | A |
5754849 | Dyer et al. | May 1998 | A |
5757925 | Faybishenko | May 1998 | A |
5761656 | Ben-Shachar | Jun 1998 | A |
5764897 | Khalidi | Jun 1998 | A |
5768532 | Megerian | Jun 1998 | A |
5774551 | Wu et al. | Jun 1998 | A |
5778228 | Wei | Jul 1998 | A |
5778368 | Hogan et al. | Jul 1998 | A |
5787425 | Bigus | Jul 1998 | A |
5787431 | Shaughnessy | Jul 1998 | A |
5790548 | Sistanizadeh et al. | Aug 1998 | A |
5805885 | Leach et al. | Sep 1998 | A |
5809507 | Cavanaugh, III | Sep 1998 | A |
5813013 | Shakib et al. | Sep 1998 | A |
5815149 | Mutschler, III et al. | Sep 1998 | A |
5815709 | Waldo et al. | Sep 1998 | A |
5815711 | Sakamoto et al. | Sep 1998 | A |
5829022 | Watanabe et al. | Oct 1998 | A |
5832529 | Wollrath et al. | Nov 1998 | A |
5832593 | Wurst et al. | Nov 1998 | A |
5835737 | Sand et al. | Nov 1998 | A |
5842018 | Atkinson et al. | Nov 1998 | A |
5844553 | Hao et al. | Dec 1998 | A |
5845129 | Wendorf et al. | Dec 1998 | A |
5860004 | Fowlow et al. | Jan 1999 | A |
5860153 | Matena et al. | Jan 1999 | A |
5864862 | Kriens et al. | Jan 1999 | A |
5864866 | Henckel et al. | Jan 1999 | A |
5872928 | Lewis et al. | Feb 1999 | A |
5875335 | Beard | Feb 1999 | A |
5878411 | Burroughs et al. | Mar 1999 | A |
5884024 | Lim et al. | Mar 1999 | A |
5884079 | Furusawa | Mar 1999 | A |
5887134 | Ebrahim | Mar 1999 | A |
5890158 | House et al. | Mar 1999 | A |
5892904 | Atkinson et al. | Apr 1999 | A |
5933497 | Beetcher et al. | Aug 1999 | A |
5935249 | Stern et al. | Aug 1999 | A |
5940827 | Hapner et al. | Aug 1999 | A |
5946485 | Weeren et al. | Aug 1999 | A |
5946694 | Copeland et al. | Aug 1999 | A |
5966531 | Skeen et al. | Oct 1999 | A |
6002867 | Jazdzewski | Dec 1999 | A |
6003763 | Gallagher et al. | Dec 1999 | A |
6009103 | Woundy | Dec 1999 | A |
6061699 | DiCecco et al. | May 2000 | A |
6061713 | Bharadhwaj | May 2000 | A |
6151639 | Tucker et al. | Nov 2000 | A |
6269373 | Apte et al. | Jul 2001 | B1 |
6275937 | Hailpern et al. | Aug 2001 | B1 |
6345382 | Hughes | Feb 2002 | B1 |
6385661 | Guthrie et al. | May 2002 | B1 |
6442619 | Ouellette | Aug 2002 | B1 |
6549955 | Guthrie et al. | Apr 2003 | B2 |
6578191 | Boehme et al. | Jun 2003 | B1 |
Number | Date | Country |
---|---|---|
0 300 516 | Jan 1989 | EP |
0 351 536 | Jan 1990 | EP |
0 384 339 | Aug 1990 | EP |
0 472 874 | Mar 1992 | EP |
0 474 340 | Mar 1992 | EP |
0 555 997 | Aug 1993 | EP |
0 565 849 | Oct 1993 | EP |
0 569 195 | Nov 1993 | EP |
0 603 880 | Dec 1993 | EP |
0 625 750 | Nov 1994 | EP |
0 635 792 | Jan 1995 | EP |
0 651 328 | May 1995 | EP |
0 660 231 | Jun 1995 | EP |
0 697 655 | Feb 1996 | EP |
0 718 761 | Jun 1996 | EP |
0 767 432 | Apr 1997 | EP |
0 778 520 | Jun 1997 | EP |
0 794 493 | Sep 1997 | EP |
0 803 810 | Oct 1997 | EP |
0 803 811 | Oct 1997 | EP |
0 805 393 | Nov 1997 | EP |
0 810 524 | Dec 1997 | EP |
0 817 020 | Jan 1998 | EP |
0 817 022 | Jan 1998 | EP |
0 817 025 | Jan 1998 | EP |
0 836 140 | Apr 1998 | EP |
2 253 079 | Aug 1992 | GB |
2 262 825 | Jun 1993 | GB |
2 305 087 | Mar 1997 | GB |
11-45187 | Feb 1999 | JP |
WO9207335 | Apr 1992 | WO |
WO9209948 | Jun 1992 | WO |
WO9403855 | Feb 1994 | WO |
WO9603692 | Feb 1996 | WO |
WO9610787 | Apr 1996 | WO |
WO9618947 | Jun 1996 | WO |
WO9624099 | Aug 1996 | WO |
WO9802814 | Jan 1998 | WO |
WO9804971 | Feb 1998 | WO |
WO 9844414 | Oct 1998 | WO |