Method and apparatus of transforming a class

A method and apparatus of transforming a class is disclosed. The class is split and converted into a modified class and/or a helper class. After the transformation, a safe class sharing among several processes is achieved whereby the startup times and the memory usage for the processes are reduced. The inter-process communication (IPC) becomes faster. The proposed mechanism is particularly suited and efficient in an object-oriented environment, such as Java.

DESCRIPTION OF THE PREFERRED INVENTION With general reference to the figures and with special reference to FIG. 2 , the essential features of transforming a class is described in more detail below. At first, some general points are addressed. Object-oriented programming is a method of program implementation in which programs are organized as cooperative collections of objects, each of which represents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships. Object-oriented programming differs from standard procedural programming in that it uses objects, not algorithms, as the fundamental building blocks for creating computer programs. This difference stems from the fact that the design focus of object-oriented programming technology is wholly different than that of procedural programming technology. The focus of procedural-based design is on the overall process used to solve the problem; whereas the focus of object-oriented design is on casting the problem as a set of autonomous entities that can work together to provide a solution. The autonomous entities of object-oriented technology are, of course, objects. Object-oriented technology is significantly different from procedural technology because problems are broken down into sets of cooperating objects instead of into hierarchies of nested computer programs or procedures. Thus, a pure object-oriented program is made up of code entities called objects. Each object is an identifiable, encapsulated piece of code and data that provides one or more services when requested by a client. Conceptually, an object has two parts, an external object interface and internal object implementation. In particular, all object implementation functions are encapsulated by the object interface such that other objects must communicate with that object through its object interface. The only way to retrieve, process or otherwise operate on the object is through the methods defined on the object. This protects the internal data portion of the object from outside tampering. Additionally, because outside objects have no access to the internal implementation, that internal implementation can change without affecting other aspects of the program. In this way, the object system isolates the requester of services (client objects) from the providers of services (server objects) by a well defined encapsulating interface. In the classic object model, a client object sends request messages to server objects to perform any necessary or desired function. The message identifies a specific method to be performed by the server object, and also supplies any required parameters. The server object receives and interprets the message, and can then decide what service to perform. There are many computer languages available today that support object-oriented programming. For example, Smalltalk, Object Pascal, C&plus;&plus; and JAVA are all examples of languages that support object-oriented programming to one degree or another. The present invention is described with reference to the Java programming language. For this reason, this description will utilize the nomenclature of Java. The following Java nomenclature is used frequently throughout the description and will be described herein briefly. A class is a grouping of instance variables and methods that is used to describe the behavior of an object. In general, a class is a software construct that defines the data (state) and methods (behavior) of the specific concrete objects that are subsequently constructed from that class. In Java terminology, a class is built out of members, which are either fields or methods. Fields are the data for the class. Methods are the sequences of statements that operate on the data. Fields are normally specific to an object that is, every object constructed from the class definition will have its own copy of the field. Such fields are known as instance variables. Similarly, methods are also normally declared to operate on the instance variables of the class, and are thus known as instance methods. An object is an instance of a class. An instance variable is the data of an object that is instantiated from a class. A static instance variable is one that will be the same for all instances of the class. A non-static instance variable varies for each instance of the class. Constant data refers to data that is not altered during program execution. A method or function is a program segment that performs a well-defined series of operations. In Java, a method is implemented by instructions represented as a stream of byte codes. A byte code is an 8-bit code that can be a portion of an instruction such as an 8-bit operand or opcode. An interface is an abstract class where the byte codes that implement the method are defined at runtime. A Java application is an executable module consisting of byte codes that can be executed using the Java interpreter or the Java just-in-time compiler. A more detailed description of the features of the Java programming language is described in Tim Ritchey, Programming with Java Beta 2.0, New Riders Publishing (1995). Java is a modern object-oriented programming language designed by Sun Microsystems that has grown in popularity in recent years. Java offers many features and advantages that makes it a desirable programming language to use. First, Java is specifically designed to create small application programs, commonly called “applets”, that can reside on the network in centralized servers, and which are delivered to the client machine only when needed. Second, Java is completely platform independent. A Java program can be written once and can then run on any type of platform that contains a Java Virtual Machine, also abbreviated as JVM. The JVM model is supported by most computer vendors, thereby allowing a software vendor to have access to hardware and software systems produced by many different companies. Finally, Java is an object-oriented language, meaning that software written in Java can take advantage of the benefits of object-oriented programming techniques. As in other object-oriented systems, operations in Java are performed by one object calling a method on another object. These objects can reside locally on the same machine or on separate JVM's physically located on separate computers or systems. A “Java process” 0 can be defined as a set of threads which is kept together by a structure called the thread group (java.lang.ThreadGroup). The “class name space” 0 of a process is defined by the class loader that loaded the initial application class, i.e. the class containing the applications main( ) method. A class loader's class name space contains classes loaded by itself and all or a subset of the classes loaded by its parent class loader. For example, the class name space of an application class loader could contain application classes plus the classes of the core Java libraries loaded by the JVM's system class loader. A thread can only access objects which are in the object closure of the threads executing in the same thread group. The “process boundary” 0 is defined by this object closure, also called the process object closure. A process object closure encompasses all objects created during the execution of one of the process' threads and still referenced from the execution stack., i.e., referenced by a method local variable. Recursively, it contains all objects referenced by objects of the object closure. It contains further all objects which are referenced from static fields of classes in the process' class name space. When the word “process” is mentioned in the following, then it refers to a Java process as mentioned above. In order to aid in the understanding of the present invention, FIG. 1 shows a high-level block diagram of a computer 100 in which a class may be transformed according to the present invention. However, those skilled in the art will appreciate that the method and apparatus of the present invention apply equally to any computer or computer system, regardless of whether the computer system is a complicated multi-user computing apparatus or a single user device such as a personal computer or workstation. The computer 100 suitably comprises a processor 110 , a main memory 120 , a memory controller 130 , a storage device or interface 140 , and a terminal interface 150 , all of which are interconnected via a system bus 160 . Various modifications, additions, or deletions may be made to the computer 100 illustrated in FIG. 1 within the scope of the present invention such as the addition of cache memory or other peripheral devices. The processor 110 performs computation and control functions of the computer 100 and comprises a suitable central processing unit (CPU). The processor 110 may comprise a single integrated circuit, such as a microprocessor, or may comprise any suitable number of integrated circuit devices and/or circuit boards working in cooperation to accomplish the functions of a processor. The processor 110 suitably executes programs or instructions within the main memory 120 . The storage device 140 allows the computer 100 to store and retrieve information. The memory controller 130 , through use of a processor (not shown) separate from the processor 110 , is responsible for moving requested information from the main memory 120 and/or through the storage device 140 to the processor 110 . While for the purposes of explanation, the memory controller 130 is shown as a separate entity, those skilled in the art understand that, in practice, portions of the function provided by the memory controller 130 may actually reside in the circuitry associated with the processor 110 , the main memory 120 , and/or the storage device 140 . The terminal interface 150 allows the computer 100 to communicate with other computers or devices. Although the computer 100 depicted in FIG. 1 contains only a single main processor 110 and a single system bus 160 , it should be understood that the present invention applies equally to computer systems having multiple processors and multiple system buses. Similarly, although the system bus 160 of the preferred embodiment is a typical hardwired, multidrop bus, any connection means that supports bi-directional communication in a computer-related environment could be used. The main memory 120 suitably contains an operating system 122 , a class transformation program 124 , a creator module 126 , and a Java byte code program 128 comprising an original class 20 and a class 30 . The creator module 126 is created and/or manipulated by some portion of the class transformation program 124 . The term “memory” 0 as used herein refers to any storage location in the virtual memory space of the computer 100 . It should be understood that the main memory 120 will not necessarily contain all parts of all mechanisms shown. For example, portions of the class transformation program 124 and operating system 122 may be loaded into an instruction cache (not shown) for processor 110 to execute, while other files may well be stored on magnetic or optical disk storage devices (not shown). In addition, although the class transformation program 124 is shown to reside in the same memory location as the operating system 122 , the creator module 126 , and the Java byte code program 128 , it is to be understood that the main memory 120 may consist of multiple disparate memory locations. The structure of the computer 100 , as described with reference to FIG. 1 , is to be seen as the underlying device that can be used to transform a class as described in the following embodiment. Referring now to FIG. 2 , where a schematic diagram of transforming a class according to the present invention is shown. FIG. 2 depicts two classes, an original class 20 and a class 30 . The original class 20 comprises here two class fields 2 and an original-class class-initialization method 3 whilst the class 30 comprises here two usage methods 5 which have accesses 42 , 43 to the class fields 2 . These usage methods 5 , also called static or class methods, can be instance methods. A first process 50 and a second process 60 are executed by use of a class loader 40 after the transformation. The first process 50 comprises a first instance 51 with instance fields 12 , and the second process 60 comprises a second instance 61 with instance fields 12 . On the one hand, the original class 20 is transformed to a helper class 21 , as indicated by the arrow labeled with “a”, and on the other hand the original class 20 is transformed to a modified-original class 22 . The class 30 is transformed to a corresponding modified class 31 , as indicated by the arrow labeled with “b”. As indicated by the dashed lines labeled with “i.”, each class field 2 is converted to an instance field 12 and introduced into the helper class 21 . Furthermore, the original-class class-initialization method 3 is converted to a helper-class instance-initialization method 13 , as indicated by the dashed line labeled with “ii.”. The helper-class 21 comprises a class-initialization method 14 that is able to create a table 15 , e.g. a hash table 15 . Instead of the hash table 15 , any structure that provides a mapping from a process or a process identifier to an instance of the helper class 21 might be used. In the modified-original class 22 , each class field 2 is replaced by an access function 23 , 24 , 25 , 26 , for example, by a read access function 23 , 25 and/or a write access function 24 , 26 . The usage methods 5 from the class 30 are converted to modified-usage methods 6 , as indicated by the broken line, whereby each former access 42 , 43 to one class field 2 is replaced by an invocation 33 , 36 of the respective access function 23 , 24 , 25 , 26 . This invocation 33 , 36 is able to fetch from the instances 51 , 61 of the helper class 21 , which are assigned to the processes 50 , 60 , the respective instance field 12 . The instance fields 12 correspond to the class fields 2 . After the transformation, the helper class 21 , the modified-original class 22 and the modified class 31 are loaded by the class loader 40 in order to run the processes 50 , 60 . Some implementation details are described with reference to FIG. 3 to 7 where the same reference numbers are used for the same elements. FIG. 3 shows the transformation, indicated by the box labeled with “T”, of a sample code 300 applied to a normal class where the original class 20 is transformed to the helper class 21 and the modified-original class 22 . The helper class 21 can be regarded as the static-part of the original class 20 whilst the modified-original class 22 as the non-static part of the original class 20 . It can be seen that class fields 2 , also referred to as static fields, of the original class 20 (A.a and A.b) show up as instance fields 12 in the helper class 21 (A_staticPart.a and A_staticPart.b). The hash table 15 (A_staticpart.ht) is used to retrieve the instance 51 , 61 of the helper class 21 that corresponds to the current process 50 , 60 . It is the only static field in any application class. It can not be used to bypass the process boundary because it is accessible only from within the helper class 21 (A_staticPart) in which it is declared private (access modifier private). In general, helper classes 21 are generated by the class transformation T which prevents user manipulations. The class-initialization method 14 , also referred to as constructor, (not shown in the figure) registers all instances of the helper class 21 within the hash table 15 . This ensures that there will be exactly one instance per process 50 , 60 . The hash table 15 provides thus the mapping from processes 50 , 60 to their corresponding process-global variables. In the original class 20 , the initialization of the class fields 2 is done in the original-class class-initialization method 3 or short class initializer method 3 (A.<clinit>( )) (not shown in the figure). The transformation moves this functionality to the constructor method also called helper-class instance initialization method 13 of the helper class 21 (A_staticPart.<init>( )) (not shown in the figure). This should be done because the transformed class fields 2 need to be initialized once per process in contrast to the one time initialization during class loading. The helper-class instance initialization method 13 of the helper class 21 is declared with a private access flag to prevent abuse. It is executed if the method A_staticPart.get( ) cannot find an instance for the current process in the hash table 15 . This guarantees that the transformed class fields 2 are correctly initialized before their first use. In cases where the class initializer method 3 (A.<clinit>( )) has side effects on class fields 2 of other classes it might be that the class initialization does not happen in the usual order or not at all. To prevent this, it should be provided that all classes whose <clinit>( ) are more complex than just initializing class fields 2 with constant values are executed on process startup in the same order as it would happen for the original classes 20 . In the modified-original class 22 , for each class field 2 access functions 23 , 24 , 25 , 26 are added, e.g., A._get a( ) as a read function 23 and A._set_a( )as a write function 24 replace the class field 2 (A.a). These access functions 23 , 24 are used to access the displaced fields. The access modifiers assigned to the class fields 2 in the original class 20 , e.g. public for A.a and private for A.b, are assigned to the corresponding access functions 23 , 24 . For class fields 2 that were declared to be constant (access modifier final), the_set_*( ) method is left out. This guarantees the original semantics. An example of an implementation of the read access function 23 A._get_a( ) is shown in FIG. 3 . It uses the method A_staticPart.get( ) to retrieve the corresponding instance of the helper class 21 and then selects and returns the field A_staticPart.a for which the method is a replacement. The implementation of the method A._set_a( ) differs only in the sense that it makes an assignment and returns a void. The removal of the class fields 2 needs to be reflected in all classes 20 , 30 that access the class fields 2 . FIG. 4 shows the transformations, indicated by the box labeled with “T”, of a sample code 400 applied on an example method 5 , method B.x( ). The write access 43 of the class field 2 is replaced with an invocation 36 of a write access function 24 A._set_a( ) and the read access 42 is replaced with an invocation 33 of the read access function 23 A._get_a( )within the modified class 31 . In the byte code this translates to replacing the byte code operations GETSTATIC and PUTSTATIC with an INVOKESTATIC byte code operation of the corresponding access function 23 , 24 , 25 , 26 . The following Table 1 summarizes the general transformations applied to the original class. 1 TABLE 1 After Transformation Before Transformation modified-original original class class helper-class class name A class name A class name A__staticPart class field a access functions instance field a _get_a() and _set_a() field access modifiers method access field access modifier modifiers public, protected, public, protected, n/a private private final, transient, n/a final, transient, volatile volatile class initialization n/a constructor <init>() method <clinit>() access to class field method invocation n/a within a method GETSTATIC A.a INVOKESTATIC _get_a() PUTSTATIC A.a INVOKESTATIC _set_a() FIG. 5 illustrates a schematic diagram of a transformation applied to an original interface or interface 510 . Compared to FIG. 2 , slightly different transformations are applied to interfaces 510 . FIG. 5 depicts the interface 510 and the class 30 . The interface 510 comprises here two class fields 2 , the original-interface class-initialization method 3 , and a method declaration 7 . The method declaration 7 has no body and contains only the signature of a method, i.e. the method name and types of arguments and the types of the return value. The class 30 , on the other hand, comprises here two usage methods 5 which have access 42 to the class fields 2 . These usage methods 5 can also be instance methods. The first process 50 and the second process 60 are executed by use of the class loader 40 after the transformation. The first process 50 comprises the first instance 51 with instance fields 12 , and the second process 60 comprises the second instance 61 with instance fields 12 . On the one hand the interface 510 is transformed to a helper class 21 and on the other hand the interface 510 is transformed to a modified interface 511 . The class 30 is transformed to the corresponding modified class 31 . As indicated by the dashed line labeled with “iii.”, each class field 2 is converted to an instance field 12 , the original-interface class-initialization method 3 is converted to a helper-class instance-initialization method 13 , and all converted elements are introduced into the helper class 21 . Moreover, the class-initialization method 14 is created and introduced into the helper-class 21 whereby this class-initialization method 14 is able to create the hash table 15 . As indicated by the dashed line labeled with “iv.”, the method declaration 7 is introduced into the modified interface 511 without any modifications. In the helper class 21 for each class field 2 of the original interface 510 , the corresponding access function 23 , 25 is introduced. For example, this may be the read access function 23 , 25 . The usage methods 5 from the class 30 are converted to modified-usage methods 6 , as indicated by the broken line, whereby each former access 42 to one class field 2 is replaced by an invocation 33 of the respective access function 23 , 25 . This invocation 33 is able to fetch from the instances 51 , 61 of the helper class 21 , which are assigned to the processes 60 , 61 , the respective instance field 12 . The instance fields 12 correspond to the class fields 2 . After the transformation, the modified interface 511 , the helper class 21 , and the modified class 31 are loaded by the class loader 40 in order to run the processes 50 , 60 . A transformation T of a sample code 600 applied to the interface 510 is indicated in FIG. 6 . Interface fields are implicitly declared public, static and final, i.e., one can not reassign new values to them. For basic types, e.g., int, double etc., this means the values are constant and thus do not affect the isolation property. However, it is assumed that in general more complex field types are used, for example a Vector, as indicated with field I.v in FIG. 6 . Such a class field 2 could be used to exchange references across process boundaries. Thus interface fields, which are always class fields 2 , also have to be moved into the helper-class 21 , as indicated in FIG. 6 . Usually, interface fields comprising constants are initialized at the very beginning and can only be read. For interfaces 510 the modified class is also an interface, here called modified interface 511 , but the helper class 21 is a normal class. A problem that appears is that interfaces 510 can contain only method declarations 7 but no method implementations. Therefore, the access functions should be moved into the helper class 21 rather than into the modified interface 511 , as shown in FIG. 5 and 6 . By doing so, the field access controls cannot be bypassed, because all interface fields are declared public, as mentioned before. FIG. 7 exemplifies the transformation T of a sample code 700 applied to accesses 42 to class fields 2 of the interface 510 . In contrast to FIG. 4 , the access functions 23 , 25 are invoked by the invocation 33 at the helper class 21 , e.g. I_staticPart._get_i( ). Table 2 summarizes the rules for the transformations that are specific to interfaces or interface classes. 2 TABLE 2 Before Transformation After Transformation Original Interface modified interface helper class interface name B interface name B class name B_staticPart class field c instance field c plus static methods_get_c() The present invention can be realized in hardware, software, or a combination of hardware and software. Any kind of computer system, or other apparatus adapted for carrying out the method described herein, is suited. A typical combination of hardware and software could be a general purpose computer system with a computer program that, when being loaded and executed, controls the computer system such that it carries out the methods described herein. The present invention can also be embedded in a computer program product, which comprises all the features enabling the implementation of the methods described herein, and which, when loaded in a computer system, is able to carry out these methods. Computer program means or computer program in the present context mean any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of (a) conversion to another language, code or notation, and (b) reproduction in a different material form. Although the present invention has been described with respect to a specific preferred embodiment thereof, various changes and modifications may be suggested to one skilled in the art and it is intended that the present invention encompass such changes and modifications as fall within the scope of the appended claims.