Patent Publication Number: US-2002007482-A1

Title: System for modifying object oriented code

Description:
BACKGROUND OF THE INVENTION  
       [0001] 1. Field of the Invention  
       [0002] The present invention is directed to a system for modifying object oriented code.  
       [0003] 2. Description of the Related Art  
       [0004] Java is an object oriented programming language that contains built-in support for the Internet, freeing the programmer from the burden of designing ad hoc solutions to common Internet problems. Java generates extremely small executables to facilitate faster loading over potentially slow communication lines. Additionally, Java is machine independent. That is, the same executable program should be capable of being executed on a PC, a Mac or even a UNIX machine. Because of these features, software developers worldwide are adopting Java technology at a compelling rate. For example, many web pages on the Internet include Java applets in addition to HTML instructions. Furthermore, many software systems are being written in Java in an attempt to allow the code to operate across many platforms.  
       [0005] While Java provides many new features useful to both programmers and users, Java also brings with it a new set of problems. One feature of Java discussed above is that it can easily be used on the Internet. Thus, rather than shrink wrap software to sell in stores, many software programs are sold on the Internet. This will allow any person anywhere in the world to download a computer program that should run on almost any platform. However, different people and different cultures may have different needs for their computer program. For example, since different languages are spoken in different parts of the world, it is desirable to have the user interface of the computer program be tailored for the local culture. Furthermore, certain people have special needs, such as color blind people may prefer gray scale user interfaces rather than color interfaces. This problem has previously been taken care of by creating different versions of a particular executable and only allowing the relevant versions to be available in stores in the local communities. With the distribution of software on the Internet, it is harder to direct the right executable to the right people. Thus, it would be useful to be able to modify software downloaded from the internet in order to add features needed by corporations, local communities and other special interests groups. Some software may need modifications (to accommodate users) that the manufacturer did not anticipate. Furthermore, rather than design and ship multiple versions of a software product it may be more cost effective to ship one version of the software and let the different user groups modify the software to meet their needs.  
       [0006] Because Java code can be run on different platforms and can be downloaded from web pages, computer users with access to the Internet or other networks can easily find and download new Java programs and install these programs on their computer. In a local area network (e.g. an office), it will be difficult to monitor all new programs being downloaded and installed. Many of these programs could wreak havoc on the network. Managers of networks have no easy way to monitor, track, profile or otherwise provide some means for understanding what users on the network are doing. A network manager would benefit from the ability to modify Java programs that are downloaded from the Internet to add functionality that profiled the downloaded code, alerted the network manager of the new program or added other security features.  
       [0007] Although Java is intended to be platform independent, different entities have implemented the Java Virtual Machine in different ways. Therefore, a Java applet may not necessarily run in the same manner on all virtual machines. In fact, some applets may not run at all on certain virtual machines. Debugging Java code to figure out why it works in some machines and not others can be very difficult. Furthermore, nobody may be aware that a certain applet does not work on a certain virtual machine until the user is attempting to execute the applet. Software developers and software users would benefit from a tool that could add functionality to an existing Java executable to add debugging tools to Java code or, to add functionality, features or bug fixes that are specific to a particular virtual machine.  
       [0008] The above discussion demonstrates a need to modify Java programs after they have been completed by the developer. Most previous attempts to modify code attempt to do so at the source code level. That is, source code is run through a compiler that can add additional instructions for profiling, debugging, etc. Since most Java code available for downloading on the web or purchasing at a store is not source code, it is not practical to modify the source code of a Java program. Most Java code downloaded or sold is object code. Object code is code that has been compiled, as distinguished from source code. Some systems can execute object code. For Java, object code is executable code. Furthermore, previous attempts to modify code have not taken into account nor taken advantage of the object oriented paradigm of Java.  
       [0009] System Object Model (SOM) is an object technology developed by IBM. SOM provides the ability at run time to replace the use of one class for another class, but does not make special provisions for a final class and it does not provide for the substitution of static fields. Furthermore, because SOM operates at run time, any changes made are not permanent. Thus, after execution is complete, the user is left with the original program rather than a modified version that can be shipped to other users. Furthermore, SOM does not work with Java and in order to use SOM the source code must be written to utilize the SOM API. It would be desirable to have a system that can modify an executable, with no preparation for the modification made in the source, and allow the modification to be permanent for distribution.  
       [0010] Thus, there is a need for a tool that can modify Java or other object oriented code to add new functionality to the existing code.  
       SUMMARY OF INVENTION  
       [0011] The present invention, roughly described, includes a code modifier that receives three sets of inputs: program class definitions, a set of rules, and additional class definitions to be merged with the original class definitions. There are three types of rules: the first rule is used to substitute the allocation of an object of a new class for the allocation of the object based on an original class; the second rule is used to change code that allocates an object of an original class to code that calls a static method in another class that allocates the object of the original class; and the third rule is used to a replace a new static field for an original static field. The system reads the program class definitions into a class data structure and performs the modifications to the class data structure according to the set of rules. Inone embodiment the system for modifying object oriented code performs the steps of reading a rule defining a change to object code defining an object oriented class, modifying the object code based on the rule, and writing the modified object code to a stream.  
       [0012] The system of the present invention can be implemented using software that is stored on a processor readable storage medium and executed using a processor. For example, the code modifier described below can be implemented in software and run on a general purpose computer. Alternatively, the invention can be implemented in specific hardware, or a combination of specific hardware and software, designed to carry out the methods described herein.  
       [0013] The code modifier of the present invention may be used change a user interface or add features specific to a particular virtual machine. The code modifier may also be used to modify existing applets used on a network to generate diagnostic or security information about the applets and send that diagnostic information to a server for presentation to a network administrator. Additionally, the code modifier can also be used to enable applets to communicate with a server on the Internet from behind a firewall by adding functionality to the applet that lets the applet redirect its communication to its original host through a proxy server on the firewall. Obviously, there are many other uses of the code modifier of the present invention. The intended use of the code modifier does not effect the design. Rather, the code modifier is designed as a generic tool that can be customized by use of the rules and the additional classes which serve as inputs.  
       [0014] These and other objects and advantages of the invention will appear more clearly from the following detailed description in which the preferred embodiment of the invention has been set forth in conjunction with the drawings. 
     
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
     [0015]FIG. 1 is a block diagram of the code modifier of the present invention.  
     [0016]FIG. 2 is a flow chart explaining the steps of using the code modifier.  
     [0017]FIG. 3 is a flow chart explaining the operation of the code modifier.  
     [0018]FIG. 4 is a flow chart explaining the process class step  42  of FIG. 3.  
     [0019]FIG. 5 depicts a symbolic representation of the class data structure.  
     [0020]FIG. 6 is a flow chart explaining the substitute class step  84  of FIG. 4.  
     [0021]FIG. 7 is a flow chart explaining the proxy class step  92  of FIG. 4.  
     [0022]FIG. 8 is a flow chart explaining the substitute static field step  98  of FIG. 4.  
     [0023]FIG. 9 is a block diagram of one exemplar hardware platform for implementing the present invention. 
    
    
     DETAILED DESCRIPTION  
     [0024]FIG. 1 shows a block diagram of the code modifier  10  of the present invention. Code modifier  10  includes three inputs. The first input includes the program classes, which are the classes to be changed. These classes could be an applet downloaded from the Internet, a Java application, or any program that conforms to the Java binary specification. The second input to code modifier  10  are the rules. There are three types of rules. The first type of rule is a substitute class rule which has the format:  
     [0025] Substitute Class: &lt;original class&gt; &lt;new class&gt;.  
     [0026] The substitute class rule instructs code modifier  10  to change the code that allocates an object of the &lt;original class&gt; to code that allocates the object to be of the &lt;new class&gt;, where the &lt;new class&gt; extends (or is a subclass of) the &lt;original class&gt;. A subclass is a first class that inherits the methods and fields of a second class, and is capable of extending or modifying the functionality of the second class. That class whose fields and methods are being inherited is called a superclass. Because a subclass inherits from the superclass and can extend the functionality of the superclass, a subclass is said to extend a superclass.  
     [0027] For Java code, the allocation of an object includes two steps: (1) creating the object and (2) invoking the object&#39;s constructor. An object&#39;s constructor is a method that is invoked once to make the object useable. For Java code, the constructor is the method &lt;init&gt;. When the present invention is used with object oriented languages other than Java, the allocation of an object may be different from what is described above.  
     [0028] The second type of rule is the proxy class rule which has the format:  
     [0029] Proxy Class: &lt;original class&gt; &lt;proxy Allocator Class&gt;.  
     [0030] The Proxy class rule instructs code modifier  10  to change the code that allocates an object of &lt;original class&gt; to code that calls a static method in &lt;proxy Allocator Class&gt;. The static method will allocate the object of &lt;original class&gt; and must accept the same arguments as the constructor. In one embodiment the &lt;original class&gt; in the proxy class rule is a final class. A final class is a class that cannot be extended. That is, it can have no subclasses. Thus, while a final class can have a superclass, a final class cannot be a superclass. A static method is defined as method that is shared among all objects. That is, a static method is one that does not operate on a single object (there is no this object). Thus, even a subroutine call can be thought of as a static method.  
     [0031] The third rule is a substitute static field rule which has the following format:  
     [0032] Substitute Static Field: &lt;original static field&gt; &lt;new static field&gt;.  
     [0033] The substitute static field rule directs code modifier  10  to substitute the &lt;new static field&gt; for the &lt;original static field&gt;. The new static field should be defined in the same class as the original static field or a subclass of the class defining the original static field. These three rules allow a user of code modifier  10  to change the functionality of an object oriented program.  
     [0034] The third input to code modifier  10  are additional classes. The set of additional classes includes some or all of the new classes and Proxy Allocator classes referenced by the rules. The inputs to code modifier  10  are one or more files. Alternatively, the inputs can be entered using a user interface or some other input/output mechanism (e.g. a network connection). The output of code modifier  10  includes the enhanced classes (e.g. the original classes after modifications) and the appropriate additional classes used according to the rules, all merged together in one or more output streams (files, network, etc.). By merged together, it is meant that they are written to the same file (e.g. zip or jar), to the same directory, or to the same storage element.  
     [0035]FIG. 2 is a flow chart which explains how code modifier  10  is used. In step  20 , a user of code modifier  10  will identify a feature in the program for which the user desires to change. The user can also desire to add a new feature to the program. For example, a user may wish to change a user interface from English to French, or change the color of the interface, or add new buttons. In step  22 , the user creates the set of additional classes that implement these changes. That is, the user writes Java software (or C++ or other object oriented code) that includes code for implementing the features the user wishes to change or add. In step  24 , the user creates a rule or set of rules to implement the change. In step  26 , code modifier  10  operates on the program classes using the rules and the set of additional classes. For example, if the color of a button is set by a static field and the user wants to change that static field, the user may create a change static field rule in step  24  and input that rule to code modifier  10  in step  26 . Alternatively, the user may wish to add a new button to a dialog box. Thus, in step  24 , the user would create a substitute class rule to substitute a new class for an original class.  
     [0036]FIG. 3 is a flow chart explaining the operation of code modifier  10 . In step  40 , code modifier  10  loads the rules into a data structure. The exact form of the data structure is not important. In step  42 , code modifier  10  processes a class from the set of program classes using the rules and set of additional classes. In step  44 , code modifier  10  determines whether there are any more classes to process. If there are more classes, then the system loops back to step  42  and processes the next original class. If there are no more classes to process (step  44 ), then the system merges the relevant additional classes with the modified program classes into a file or set of files. While it is anticipated that the &lt;original class&gt; referenced in the rules is from the set of program classes and the &lt;new class&gt; is from the set of additional classes, such an arrangement is not required. For example, both the &lt;new class&gt; and the &lt;original class&gt; can be from the set of program classes. Other variations can also exist.  
     [0037]FIG. 4 is a flow chart explaining the details of step  42  of FIG. 3. In step  80 , code modifier  10  loads a class into a class data structure. In step  82 , code modifier  10  determines whether there is another substitute class rule in the rule data structure which has not been implemented on the current class loaded into the class data structure. If there is another substitute class rule, then code modifier  10  performs the substitute class method  84  and then loops back to step  82 . If there are no more substitute class rules to implement for the current class, then code modifier  10  determines whether there is another proxy class rule in the rule data structure which has not been implemented on the current class (step  90 ). If so, the system performs proxy class method  92  and loops back to step  90 . When there are no more proxy class rules to consider, the system determines whether there are any more substitute static field rules (step  96 ). If there is another substitute field rule in the rules data structure which has not been implemented on the current class (step  96 ), then code modifier  10  performs the substitute static field method  98  for that substitute static field rule and loops back to step  96 . When there are no more substitute static field rules to consider, the system writes the enhanced (or possibly unmodified) class to an output stream in step  100 . The output stream can be sent to a file, a network connection, a memory buffer, a monitor or any other output mechanism. The enhanced class can be written to a new file or written over the old file. In one embodiment, code modifier  10  can partially write over the old file by leaving the instructions that have not changed and writing over the instructions that have been modified.  
     [0038]FIG. 5 is a symbolic representation of the class data structure which holds the code for a class. The term code is used to refer to all of the instructions, variables, definitions, pointers, addresses etc, that are stored in a class file and/or a class data structure. Magic item  202  supplies the magic number identifying the class file. The values of the minor version  204  and major version  206  items are the minor and major version numbers of the compiler that produced the class file. Constant pool count item  208 , which must be greater than zero, provides the number of entries in the constant pool. The constant pool entry at index zero is included in the count but is not present in the constant pool. A constant pool index is considered valid if it is greater than zero and less than constant pool count  208 . The constant pool is a table of variable length structures representing various string constants, class names, field names, integers, floating point numbers and other constants that are referred to within the class file structure and its substructures. Each of the constant pool entries at indices 1 through constant pool count-1 is a variable-length structure whose format is indicated by its first “tag” byte.  
     [0039] The value of access flags item  214  is a mask of modifiers used with class and interface declarations. The access flags modifiers are public, final, super, interface and abstract. The value of this class item  214  must be a valid index into the constant pool table. The constant pool entry at that index must be a CONSTANT_Class_info structure representing the class or interface defined by this class file. For a class, the value of superclass item  216  either must be zero or must be a valid index into the constant pool. If the value of the superclass item is nonzero, the constant pool entry at that index must be a CONSTANT_Class_info structure representing the superclass of the class defined by this class file. Neither the superclass nor any of its superclasses may be a final class. If the value of a superclass item is zero, then this class file must represent the class java.lang.Object, the only class or interface without a superclass.  
     [0040] The value of interfaces count item  218  provides the number of direct superinterfaces of this class or interface type. Each value in the interfaces array  220  must be a valid index into the constant pool. The constant pool entry at each value of interfaces[i], where 0≦i&lt;interfaces count, must be a CONSTANT_Class_info structure representing an interface which is a direct superinterface of this class or interface type. The value of the fields count item  222  provides the number of field_info structures in the fields table  224 . The field_info structures represent all fields, both class variables and instance variables, declared by this class or interface type. Each value in the fields must be a variable-length field_info structure giving a complete description of a field in the class or interface type. The fields table includes only those fields that are declared by this class or interface. It does not include item fields that are inherited from superclasses or superinterfaces.  
     [0041] The value of methods count item  226  provides the number of method_info structures in methods table  228 . Each value in methods table  228  must be a variable-length method_info structure providing a complete description of the Java Virtual Machine code for a method in the class or interface. The method_info structures represent all methods, both instance methods and, for classes, class (static) methods, declared by this class or interface type. Methods table  228  only includes those methods that are explicitly declared by this class. Interfaces have only the single method, the interface initialization method. The methods table does not include items representing methods that are inherited from superclasses or superinterfaces.  
     [0042] The value of the attributes count item  230  provides the number of attributes in attributes table  232 . Each value of attributes table  232  must be a variable-length attribute structure. A class data structure can have any number of attributes associated with it. More information about ClassFile formats and the Java Virtual Machine can be found in The Java Virtual Machine Specification, Tim Lindholm and Frank Yellin, Addison-Wesley, 1997, incorporated herein by reference.  
     [0043] All constant pool entries have the following general format:  
                                  cp_info {                         tag;           info[];                 }                  
 
     [0044] Each item in the constant pool must begin with a 1-byte tag indicating the type of cp_info entry. The contents of the info array varies with the value of the tag. The valid tags and their values are CONSTANT_Class, CONSTANT_Fieldref, CONSTANT_Methodref, CONSTANT_InterfaceMethodref, CONSTANT_String, CONSTANT_Integer, CONSTANT_Float, CONSTANT_Long, CONSTANT_Double, CONSTANT_NameAndType, CONSTANT_Utf8. The following discussion explains the different types of constant pool entries.  
     [0045] The CONSTANT_Class_info structure is used to represent a class or an interface:  
                                  CONSTANT_Class_info {                         u1 tag;           u2 name index;                 }                  
 
     [0046] The tag item has the value CONSTANT_Class. The value of the name_index item must be a valid index into the constant pool. The constant pool entry at that index must be a CONSTANT_Utf8_info structure representing a valid fully qualified Java class name that has been converted to the class file&#39;s internal form. The values u1, u2 and u4 represent an unsigned one, two or four byte quantities, respectively.  
     [0047] Fields, methods, and interface methods are represented by similar structures:  
                                  CONSTANT_Fieldref_info {                         u1 tag;           u2 class_index;           u2 name_and_type_index;                 }       CONSTANT_Methodref_info {                         u1 tag;           u2 class_index;           u2 name_and_type_index;                 }       CONSTANT_InterfaceMethodref_info {                         u1 tag;           u2 class_index;           u2 name_and_type_index;                 }                  
 
     [0048] The tag item of a CONSTANT_Fieldref_info structure has the value CONSTANT_Fieldref. The tag item of a CONSTANT_Methodref_info structure has the value CONSTANT_Methodref. The tag item of a CONSTANT_InterfaceMethodref_info structure has the value CONSTANT_InterfaceMethodref.  
     [0049] The value of the class_index item must be a valid index into the constant pool. The constant pool entry at that index must be a CONSTANT_Class_info structure representing the class or interface type that contains the declaration of the field or method.  
     [0050] The value of the name_and_type_index item must be a valid index into the constant pool. The constant pool entry at that index must be a CONSTANT_NameAndType_info structure. This constant pool entry indicates the name and descriptor of the field or method.  
     [0051] The CONSTANT_String_info structure is used to represent constant objects of the type java.lang.String:  
                                  CONSTANT_String_info {                         u1 tag;           u2 string_index;                 }                  
 
     [0052] The tag item of the CONSTANT_String_info structure has the value CONSTANT_String. The value of the string_index item must be a valid index into the constant pool. The constant pool entry at that index must be a CONSTANT_Utf8_info structure representing the sequence of characters to which the java.lang. String object is to be initialized.  
     [0053] The CONSTANT_Integer_info and CONSTANT_Float_info structures represent four-byte numeric (int and float) constants:  
                                  CONSTANT_Integer_info {                         u1 tag;           u4 bytes;                 }       CONSTANT_Float_info {                         u1 tag;           u4 bytes;                 }                  
 
     [0054] The tag item of the CONSTANT_Integer_info structure has the value CONSTANT_Integer. The tag item of the CONSTANT_Float_info structure has the value CONSTANT_Float. The bytes item of the CONSTANT_Integer_info structure contains the value of the int constant. The bytes of the value are stored in big-endian (high byte first) order. The bytes item of the CONSTANT_Float_info structure contains the value of the float constant in IEEE  754  floating-point “single format” bit layout. The bytes of the value are stored in big-endian (high byte first) order, and are first converted into an int argument.  
     [0055] The CONSTANT_Long_info and CONSTANT_Double_info represent eight-byte numeric (long and double) constants:  
                                  CONSTANT_Long_info {                         u1 tag;           u4 high bytes;           u4 low bytes;                 }       CONSTANT_Double_info {                         u1 tag;           u4 high bytes;           u4 low bytes;                 }                  
 
     [0056] All eight-byte constants take up two entries in the constant pool. If a CONSTANT_Long_info or CONSTANT_Double_info structure is the item in the constant pool at index n, then the next valid item in the pool is located at index n+2. The constant pool index n+1 must be considered invalid and must not be used.  
     [0057] The tag item of the CONSTANT_Long_info structure has the value CONSTANT_Long. The tag item of the CONSTANT_Double_info structure has the value CONSTANT_Double. The unsigned high_bytes and low_bytes items of the CONSTANT_Long structure together contain the value of the long constant ((long)high_bytes&lt;&lt;32)+low_bytes, where the bytes of each of highbytes and low_bytes are stored in big-endian (high byte first) order. The high_bytes and low_bytes items of the CONSTANT_Double_info structure contain the double value in IEEE 754 floating point “double format” bit layout. The bytes of each item are stored in big-endian (high byte first) order.  
     [0058] The CONSTANT_NameAndType_info structure is used to represent a field or method, without indicating which class or interface type it belongs to:  
                                  CONSTANT_NameAndType_info {                         u1 tag;           u2 name_index;           u2 descriptor_index                 }                  
 
     [0059] The tag item of the CONSTANT_NameAndType_info structure has the value CONSTANT_NameAndType. The value of the name_index item must be a valid index into the constant pool. The constant pool entry at that index must be a CONSTANT_Utf8_info structure representing a valid Java field name or method name. The value of the descriptor_index item must be a valid index into the constant pool. The constant_pool entry at that index must be a CONSTANT_Utf8_info structure representing a valid Java field descriptor or method descriptor.  
     [0060] The CONSTANT_Utf8_info structure is used to represent constant string values:  
                                  CONSTANT_Utf8_info {                         u1 tag;           u2 length;           bytes [length];                 }                  
 
     [0061] The tag item of the CONSTANT_Utf8_info structure has the value CONSTANT_Utf8. The value of the length item gives the number of bytes in the bytes array (not the length of the resulting sring). The strings in the CONSTANT_Uff8_info structure are not null-terminated. The bytes array contains the bytes of the string. No byte may have the value (byte) 0  or (byte) 0 xf 0 -(byte) 0 xff.  
     [0062] Each field (see FIG. 5—fields  224 ) is described by a variable-length field_info structure. The format of this structure is  
                                  field_info {                         u2 access_flags;           u2 name_index;           u2 descriptor_index;           u2 attributes_count;           attribute_info attributes [attributes_count];                 }                  
 
     [0063] The value of the access_flags item is a mask of modifiers used to describe access permission to and properties of a field. The access_flags modifiers are public, private, protected, static, final, volatile and transient.  
     [0064] The value of the name_index item must be a valid index into the constant pool. The constant pool entry at that index must be a CONSTANT_Utf8_info structure which must represent a valid Java field name. The value of the descriptor_index item must be a valid index into the constant pool. The constant pool entry at that index must be a CONSTANT_Utf8 structure which must represent a valid Java field descriptor. The value of the attributes_count item indicates the number of additional attributes of this field. Each value of the attributes table must be a variable-length attribute structure. A field can have any number of attributes associated with it.  
     [0065] Each method (see FIG. 5—methods  228 ), is described by a variable-length method_info structure. The structure has the following format:  
                                  method_info {                         u2 access_flags;           u2 name_index;           u2 descriptor_index;           u2 attributes_count;           attribute_info attributes [attributes_count];                 }                  
 
     [0066] The value of the access_flags item is a mask of modifiers used to describe access permission to and properties of a method. The access_flags modifiers are public, private, protected, static, final, synchronized, native and abstract. The value of the name_index item must be a valid index into the constant pool. The constant pool entry at that index must be a CONSTANT_Utf8_info structure representing either one of the special internal method names, either &lt;init&gt; or &lt;clinit&gt;, or a valid Java method name. The value of the descriptor_index item must be a valid index into the constant pool. The constant pool entry at that index must be a CONSTANT_Utf8_info structure representing a valid Java method descriptor. The value of the attributes_count item indicates the number of additional attributes of this method. Each value of the attributes table must be a variable-length attribute structure. A method can have a number of optional attributes associated with it.  
                                  Attributes have the following general format:       attribute_info {                         u2 attribute_name_index;           u4 attribute_length;           u1 info [attribute_length];                 }                  
 
     [0067] The attribute_name_index must be a valid unsigned 16 bit index into the constant pool of the class. The constant pool entry at the attribute_name_index must be a CONSTANT_Utf8_info structure representing the name of the attribute. The value of the attribute_length item indicates the length of the subsequent information in bytes. The length does not include the initial 6 bytes that contain the attribute_name_index and attribute_length items. More information about the attributes can be found in the Java Virtual Machine Specification, referenced above. Note that FIG. 5 shows all the data in one giant contiguous data structure. In reality, the data structure of FIG. 5 can be made up of many separate substructures. That is, many separate data structures can be used to store the components of data shown in FIG. 4. Each of these separate data structures are said to be one sub-component of the class data structure. In other words, the class data structure can be a combination of subcomponents or data structures.  
     [0068]FIG. 6 is a flow chart which explains the method of the substitute class step  84  of FIG. 4. In step  300  of FIG. 6, code modifier  10  looks through the constant pool for an entry referencing the &lt;original class&gt; to be substituted for. For purposes of this patent, the term “reference” or “point to” means a direct reference or an indirect reference. An indirect reference is a reference to one or more other levels of references that eventually point to the desired destination or item. In practice, in step  300  code modifier  10  looks through the constant pool at the CONSTANT_Class_info structures. Each structure will have a name index pointing to a CONSTANT_Utf8_info structure. Code modifier  10  looks for the CONSTANT_Utf8_info structure that stores the string that matches the name of original class specified in the rule. If there is no reference in the constant pool to the original class (step  302 ), then the method of FIG. 6 is finished (step  304 ). If the original class is found in the constant pool, then, in step  306 , code modifier  10  adds to the constant pool a new CONSTANT_Class_info structure and a new CONSTANT_Utf8_info structure. The CONSTANT_Utf8_info structure would include the name of the new class and the CONSTANT_Class_info structure would include a reference to the newly added CONSTANT_Utf8_info structure.  
     [0069] After making the additions to the constant pool, the system will test whether the superclass needs to be changed (step  308 ). That is, if the string eventually referred to by the index stored at superclass  216  is the original class in the substitute class rule, the superclass needs to be changed. If the superclass needs to be changed, the data in superclass  216  is changed to reflect the new class from the substitute field rule (step  310 ). After performing step  310 , or if the superclass does not need to be changed, code modifier  10  determines whether any method in the current class under consideration need to be processed (step  320 ). Assuming that the current class has a method, the first time step  320  is performed no methods have been processed, thus, the answer to the test of step  320  is yes and code modifier  10  performs step  324  which involves looking at the code for the next method to be processed. If all the methods have already been processed, then the test of step  320  would fail and the method of FIG. 6 would be completed (step  322 ). When looking at the code for the method under consideration, the system will consider the next instruction in sequence (step  326 ). The system tests whether the next instruction is a “new” instruction in step  330 . A “new” instruction is used to create a new object, which is the first step in allocating an object. Since the “new” instruction is used to create a new object it is called a creation instruction. The “new” instruction has the following form: new indexbyte 1  indexbyte 2 . The unsigned indexbyte 1  and indexbyte 2  are used to construct an index into the constant pool where the value of the index is (indexbyte 1 &lt;&lt;8)|indexbyte 2 . The item at the index in the constant pool must be a CONSTANT_Class_info structure.  
     [0070] If the next instruction is a “new” (step  330 ), then code modifier  10  determines whether the class pointed to by the index in the “new” instruction is subject to the rule under consideration (step  332 ). That is, is the class eventually pointed to by the index the original class defined in the rule. If not, code modifier  10  proceeds to step  350 . If the class pointed to by the index is the original class defined in the rule (step  332 ), then, in step  334 , code modifier  10  will change the index for the new instruction to point to the CONSTANT_Class_info structure added to the constant pool in step  306 . After changing the constant pool index in step  334 , code modifier  10  will test whether there any more instructions in the current method that need to be considered (step  336 ). If there are more instructions to consider, code modifier  10  loops back to step  326  and considers the next instruction. If there are no more instructions to consider, code modifier  10  will loop back to step  320  to determine whether any more methods for the current class need to be processed. If in step  332  code modifier  10  determines that the class pointed to by the “new” instruction is not subject to the rule (e.g. not the original class), then code modifier  10  loops to step  336 .  
     [0071] If (in step  330 ) code modifier  10  determines that the next instruction is not a “new,” then code modifier  10  loops to step  350  and determines whether the instruction is an “invokespecial.” If the instruction is not an “invokespecial,” then code modifier  10  aligns the program counter for all other types of instructions and tests to see whether there are any more instructions for the current method in step  336 . The “invokespecial” instruction invokes an instance method. The format of an “invokespecial” instruction is: invokespecial indexbyte 1  indexbyte 2 . The unsigned indexbyte 1  and indexbyte 2  are used to construct an index into the constant pool of the current class, where the index is (indexbyte 1 &lt;&lt;8)|indexbyte 2 . The item at that index in the constant pool must be a CONSTANT_Methodref_info structure, which itself points to a CONSTANT_Class_info structure. If the class referred to by the underlying CONSTANT_class_info structure is the original class of the rule under consideration, then code modifier  10  adds a CONSTANT_Methodref_info structure to the constant pool whose class_index points to the CONSTANT_Class_info entry in the constant pool added in step  306  and whose name_and_type index is the same as the name_and_type index of the original CONSTANT_Methodref_info structure. In step  356 , the constant pool index for invokespecial is changed to point to the CONSTANT_Method_info structure added in step  354  and code modifier  10  proceeds to step  336 . Similarly, if in step  352 , code modifier  10  determines that the underlying class pointed to by the index for the “invokespecial” is not the original class defined in the rule, then code modifier  10  will proceed directly to step  336 .  
     [0072]FIG. 7 is a flow chart which explains proxy class step  92  of FIG. 4. Thus, FIG. 7 explains the operation of carrying out the modifications according to the current proxy class rule under consideration on the class currently loaded into the class data structure. The method starts at step  400 , at which time code modifier  10  looks through the constant pool for a reference to the original class stated in the proxy class rule. This step is similar to step  300  of FIG. 6. If the original class is not found (test in step  402 ), then the method of FIG. 7 is completed (step  404 ). If a reference to the original class is found, then (in step  406 ) code modifier  10  adds to the constant pool a new CONSTANT_Utf8_info structure which stores the name of the new class and a new CONSTANT_Class_info structure which points to the newly added CONSTANT_Uff8_info structure. After adding the new entries to the constant pool, code modifier  10  determines whether any methods in the current class have not yet been processed (step  420 ). If all the methods have been processed, then the method of FIG. 7 is completed (step  422 ). If there are more methods to process, then code modifier  10  looks at the code for the next method to be processed in step  424 . In step  426 , code modifier  10  considers the next instruction of the current method being processed. If that instruction is a “new” (step  428 ), then code modifier  10  determines whether the class pointed to by the index for the “new” is the original class in the proxy rule (step  430 ). If so, the new instruction (including its index) is replaced with a “nop” (step  432 ). A “nop” is an instruction that performs no operation. Sometimes a “new” instruction is followed with a “dup” instruction. If so, the dup instruction is also replaced with a “nop.” A “dup” is an instruction that duplicates the top operand stack word. After replacing the “new” and “dup” instructions, code modifier  10  determines whether any more instructions need to be considered for the current method (step  434 ). If so, code modifier  10  loops back to step  426  and considers the next instruction. If there are no more instructions in the current method, then code modifier  10  loops back to step  420  and determines whether any additional methods need be processed. If in step  430  code modifier  10  determines that the class pointed to by the index for the “new” is not the original class stated in the proxy rule, then code modifier  10  proceeds to step  434 .  
     [0073] If, in step  428 , code modifier  10  determines that the instruction being considered is not a “new” then code modifier  10  proceeds to step  450  and determines whether the instruction is an “invokespecial.” If the instruction is not an “invokespecial,” then code modifier  10  proceeds to step  434  to determine whether there are any more instructions in the current method. If the instruction is an “invokespecial,” then code modifier  10  determines whether the class pointed to by the index is the original class of the proxy class rule (step  452 ). If it is not the original class, code modifier  10  loops to step  434 . If it is the original class, code modifier  10  adds to the constant pool a new CONSTANT_NameAndType_info structure and two CONSTANT_Utf8 info structures which store the strings for the name and type. Step  454  also includes adding a CONSTANT_Methodref_info structure to the constant pool, whose class_index points to the CONSTANT_Class_info structure added in step  406  and whose name_and_type index points to the CONSTANT_NameAndType_info structure added in step  454 . In step  456 , code modifier  10  changes the “invokespecial” to a “invokestatic.” The “invokestatic” is given a constant pool index pointing to the CONSTANT_Methodref_info structure added in step  454 .  
     [0074]FIG. 8 is a flow chart which explains the method of the substitute static field step  98  of FIG. 4. That is, FIG. 8 explains the steps necessary to perform the code modifications according to the substitute static field rule currently under consideration on the class currently loaded into the class data structure. The method starts at step  500  with the code modifier  10  searching the constant pool for original static field cited in the current rule. That is, code modifier  10  will search the constant pool for CONSTANT_Fieldref_info structures, and look at the CONSTANT_Utf8_info structure eventually pointed to which stores the name of the field to determine if it matches the name of the original static field. If the original static field is not found (step  502 ), then the method of FIG. 8 is done (step  504 ). If the original static field is found (step  502 ), then code modifier  10  proceeds to step  506  and adds to the constant pool a CONSTANT_Utf8_info structure storing the name of the class defining the new static field. In step  506 , code modifier  10  adds to the constant pool a CONSTANT_Utf8_info structure storing the name of the new static field. In step  510 , code modifier  10  adds a CONSTANT_Utf8_info structure storing the field descriptor for the new static field. In step  512 , code modifier  10  adds a new CONSTANT_Class_info structure into the constant pool, having a name_index pointing to the CONSTANT_Utf8_info structure added in step  506 . In step  514 , code modifier  10  adds to the constant pool a new CONSTANT_NameAndType_info structure, which will have a name_index pointing to the CONSTANT_Utf8_info structure added in step  508  and a descriptor index pointing to the CONSTANT_Utf8_info structure added in step  510 . In step  516 , the class_index and name_and_type_index for the CONSTANT_Fieldref_info structure of the original field under consideration are changed to point to the CONSTANT_Class_info structure and the CONSTANT_NameAndType_info structures added in steps  512  and  514 .  
     [0075] To better explain the principals discussed above, consider the following example. Suppose a user of code modifier  10  has an original Java program that is an applet that presents a push button. The following Java source code will represent that example Java applet (SampleAppletjava):  
                               SampleApplet.java                  // import user interface and classes supplied       // by the java standard api       import java.awt.Button;       import java.awt.Color;       import java.applet.Applet;       // this simple applet presents a push button.       public class SampleApplet extends Applet       {                         // when the applet is created, add a push           // button to the applet&#39;s visible area           public SampleApplet ()           {                         // create a string object that stores the tile           String title = new String (“Simple Applet”);           // create a button and place it in the applet           add (new Button (title));           // set the applet&#39;s background color to yellow           setBackground (Color.yellow);                         }                 }                  
 
     [0076] If the above applet was compiled, an object code file would be created which included instructions from the instructions set for the Java Virtual Machine. The file below, Before.txt is a human readable disassembly of the Java object code corresponding to the SampleApplet above. Note that for the instructions which construct an index into the constant pool from two index bytes, the file below only shows the constructed index. For example, at line 4, the “new” instruction has a “#8” next to the code for “new.” This #8 is the constructed index into the constant pool. Next to the index is “&lt;Class Java.lang.String&gt;.” That identified class is the class pointed to by the index (identified by the CONSTANT_Class_info structure).  
                               Before.txt                  Compiled from SampleApplet.java       public synchronized class SampleApplet extends java.applet.Applet                         /* ACC_SUPER bit set */                 {                         public SampleApplet();                 }       Method SampleApplet()                          0 aload_0             1 invokespecial #9 &lt;Method java.applet.Applet()&gt;            4 new #8 &lt;Class java.lang.String&gt;            7 dup            8 ldc #1 &lt;String “Simple Applet”&gt;           10 invokespecial #11 &lt;Method java.lang.String(java.lang.             String)&gt;           13 astore_1           14 aload_0           15 new #4 &lt;Class java.awt.Button&gt;           18 dup           19 aload_1           20 invokespecial #10 &lt;Method java.awt.Button(java.lang.String)&gt;           23 invokevirtual #12 &lt;Method java.awt.Component             add(java.awt.Component)&gt;           26 pop           27 aload_0           28 getstatic #14 &lt;Field java.awt.Color yellow&gt;           31 invokevirtual #13 &lt;Method void setBackground(java.awt.Color)&gt;           34 return                      
 
     [0077] Suppose, for this example, that the user of code modifier  10  intends to make three changes. First, the user wants to replace the class Button with a new class RedButton, so that wherever a Java program calls for a button, a RedButton will appear. The second change is that anywhere in the applet there is a use of the color yellow, the user wants green to be used instead. The third change may be that the user wants all text displayed on the GUI to be uppercase. To effectuate these changes, the user needs to do at least two things. First, the user needs to set up a rules file and second, the user needs to create the additional classes. An example of a rules file (Sample.di) is shown below. The rules file contains three rules. The first rule is a substitute class rule which substitutes the RedButton class for the Button class. The second rule is a substitute static field rule that substitute green for yellow. The third rule is a proxy class rule to proxy java/lang/String using UpperCaseProxyString.  
     [0078] Sample.di  
     [0079] # 
     [0080] # Rules file  
     [0081] # 
     [0082] # This file specifies how the code modifier  
     [0083] # will modify the class inheritance structure  
     [0084] # of its target class files.  
     [0085] # 
     [0086] # Replacement classes (e.g., RedButton) are supplied in  
     [0087] # the following file  
     [0088] MergeFile: mergeclasses.jar  
     [0089] # replace all allocations. and subclassing of java/awt/Button with RedButton  
     [0090] SubstituteClass: java/awt/Button RedButton  
     [0091] # change all references to the color “yellow” to be the color “green” 
     [0092] SubstituteStaticField: java.awt.Color.yellow java.awt.Color.green  
     [0093] # use a proxy constructor for all allocations of java/lang/String  
     [0094] ProxyClass: java/lang/String UpperCaseProxyString  
     [0095] Below is the definition of the RedButton class. This source is stored in a file called RedButton.java. The object code for RedButton.java is part of a package of class files found in mergeclass.jar, which represents the additional classes submitted to code modifier  10 .  
                               RedButton.java                  import java.awt.Button;       import java.awt.Color;       // this is an extension of a simple button. The Diagnos       // System will automatically replace allocations of objects       // of type, “Button” with “RedButton”. In effect, this will       // make all buttons in the modified program be red.       public class RedButton extends Button       {                         // when the button is constructed, set the color to red           public RedButton ()           {                         // call the inherited constructor           super ();           // set the color to red           setBackground (Color.red);                         }           // This is also a constructor for the button.           // also set the color to red when this constructor is called.           public RedButton (String title)           {                         // call the inherited constructor           super (title);           // set the color to red           setBackground (Color.red);                         }           }                      
 
     [0096] Below is the definition for UpperCaseProxyString. The source will be stored in a file called UpperCaseProxyString.java. The object code for UpperCaseProxyString.java is part of a package of class files found in mergeclass.jar, which represents the additional classes submitted to code modifier  10 .  
                               UpperCaseProxyString.java                  import java.io.UnsupportedEncodingException;       // this is a proxy allocator for strings to demonstrate the       // final class allocation substitution funtionality of       // the code modifier. This sample version simply converts       // the string to upper case       public class UpperCaseProxyString       {                         // there must be one “proxy allocator” for each public           // constructor of the class we are proxying (i.e., String)           // the proxy allocator must return the newly allcoated           // string, and must have the same prototype (parameter list)           // as its corresponding constructor in the String class           public static String createProxyObject ()           {                         return new String ();                         }           public static String createProxyObject (byte[] b)           {                         return new String (b).toUpperCase ();                         }           public static String createProxyObject (byte[] b, int i)           {                         return new String (b, i).toUpperCase ();                         }           public static String createProxyObject (byte[] b, int i, int j)           {                         return new String (b, i, j).toUpperCase ();                         }           public static String createProxyObject (byte[] b, int i, int j, int k)           {                         return new String (b, i, j, k).toUpperCase ();                         }           public static String createProxyObject (byte[] b, int i, int j, String s)                         throws UnsupportedEncodingException                         {                         return new String (b, i, j, s).toUpperCase ();                         }           public static String createProxyObject (char[] c)           {                         return new String (c).toUpperCase ();                         }           public static String createProxyObject (char[] c, int i, int j)           {                         return new String (c, i, j).toUpperCase ();                         }           public static String createProxyObject (String s)           {                         return new String (s).toUpperCase ();                         }           public static String createProxyObject (StringBuffer s)           {                         return new String (s).toUpperCase ();           }                         }                      
 
     [0097] The code from UpperCaseProxyString.java and RedButton.java, Sample.di (the rules) and the code represented by Before.txt would be inputs to code modifier  10 . Code modifier  10  would operate on these inputs as described above and produce an output. Below is a disassembly of a sample output (After.txt) showing the results of enhancing Before.txt.  
                               After.txt                  public synchronized class SampleApplet extends java.applet.Applet                         /* ACC_SUPER bit set */                 {                         public SampleApplet();                 }       Method SampleApplet()                          0 aload_0            1 invokespecial #9 &lt;Method java.applet.Applet()&gt;            4 nop            5 nop            6 nop            7 nop            8 ldc #1 &lt;String “Simple Applet”&gt;           10 invokestatic #52 &lt;Method java.lang.String             createProxyObject(java.lang.String)&gt;           13 astore_1           14 aload_0           15 new #45 &lt;Class RedButton&gt;           18 dup           19 aload_1           20 invokespecial #46 &lt;Method RedButton(java.lang.String)&gt;           23 invokevirtual #12 &lt;Method java.awt.Component             add(java.awt.Component)&gt;           26 pop           27 aload_0           28 getstatic #14 &lt;Field java.awt.Color green&gt;           31 invokevirtual #13 &lt;Method void setBackground(java.awt.Color)&gt;           34 return                       
 
     [0098] As can be seen from the above code, all three rules in Sample.di were implemented on the sample java applet. For example, the proxy class rule requested the use of UpperCaseProxyString as a proxy for allocations of java/lang/String. As explained in the method of FIG. 7, the new and dup of lines 4 and 7 from Before.txt have been changed to nops on lines 4-7 of After.txt, and invokespecial (line 10 of Before.txt) was changed to invokestatic with the appropriate constant pool-index. The substitute class rule was performed by changing the indexes of both the “new” on line 15 and the invokespecial on line 20. Finally, on line 28, the static field reference was changed from yellow to green.  
     [0099]FIG. 9 illustrates a high level block diagram of a general purpose computer system which can be used to run the software that implements code modifier  10 . Computer system  600  contains a processor unit  612  and main memory  614 . Processor unit  612  may contain a single microprocessor, or may contain a plurality of microprocessors for configuring computer system  600  as a multi-processor system. Main memory  614  stores, in part, instructions and data for execution by processor unit  612 . If the system for modifying code of the present invention is wholly or partially implemented in software, main memory  614  stores the executable code when in operation. Main memory  614  may include banks of dynamic random access memory (DRAM), as well as high speed cache memory.  
     [0100] Computer system  600  further includes a mass storage device  616 , peripheral device(s)  618 , input device(s)  620 , portable storage medium drive(s)  622 , a graphics subsystem  624  and an output display  626 . For purposes of simplicity, the components in computer system  600  are shown in FIG. 9 as being connected via a single bus  628 . However, computer system  600  may be connected through one or more data transport means. For example, processor unit  612  and main memory  614  may be connected via a local microprocessor bus, and the mass storage device  616 , peripheral device(s)  618 , portable storage medium drive(s)  622 , graphics subsystem  624  may be connected via one or more input/output ( 1 /O) buses. Mass storage device  616 , which may be implemented with a magnetic disk drive or an optical disk drive, is a non-volatile storage device for storing data and instructions for use by processor unit  612 . In one embodiment, mass storage device  16  stores the system software implementing code modifier  10  for purposes of loading to main memory  614 .  
     [0101] Portable storage medium drive  622  operates in conjunction with a portable non-volatile storage medium, such as a floppy disk, to input and output data and code to and from computer system  600 . In one embodiment, the system software for modifying object code is stored on such a portable medium, and is input to the computer system  600  via the portable storage medium drive  622 . Peripheral device(s)  618  may include any type of computer support device, such as an input/output (I/O) interface, to add additional functionality to the computer system  600 . For example, peripheral device(s)  618  may include a network interface card for interfacing computer system  600  to a network, a modem, etc.  
     [0102] Input device(s)  620  provide a portion of the user interface for a user of computer system  600 . Input device(s)  620  may include an alpha-numeric keypad for inputting alpha-numeric and other key information, or a cursor control device, such as a mouse, a trackball, stylus, or cursor direction keys. In order to display textual and graphical information, computer system  600  contains graphics subsystem  624  and the output display  626 . Output display  626  may include a cathode ray tube (CRT) display, liquid crystal display (LCD) or other suitable display device. Graphics subsystem  624  receives textual and graphical information, and processes the information for output to output display  626 . Output display  626  can be used to report the results of a code modification. The components contained in computer system  600  are those typically found in general purpose computer systems, and are intended to represent a broad category of such computer components that are well known in the art. The system of FIG. 9 illustrates one platform which can be used for the present invention. Numerous other platforms can also suffice, such as Macintosh-based platforms available from Apple Computer, Inc., platforms with different bus configurations, networked platforms, multi-processor platforms, other personal computers, workstations, mainframes, routers, and so on.  
     [0103] The Detailed Description above explains the details of practicing the current invention on Java code. It is contemplated that the current invention can be used with other object oriented programming languages or binary architectures. With each different language or architecture many of the details of implementing the current invention may change; however, the overall inventive concept claimed may remain the same.  
     [0104] The foregoing detailed description of the invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed, and obviously many modifications and variations are possible in light of the above teaching. The described embodiments were chosen in order to best explain the principles of the invention and its practical application to thereby enable others skilled in the art to best utilize the invention in various embodiments and with various modifications as are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the claims appended hereto.