US20020007482A1 - System for modifying object oriented code - Google Patents

System for modifying object oriented code Download PDF

Info

Publication number
US20020007482A1
US20020007482A1 US09/839,056 US83905601A US2002007482A1 US 20020007482 A1 US20020007482 A1 US 20020007482A1 US 83905601 A US83905601 A US 83905601A US 2002007482 A1 US2002007482 A1 US 2002007482A1
Authority
US
United States
Prior art keywords
class
code
changing
instruction
modifying
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US09/839,056
Inventor
Lewis Cirne
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Wily Technology Inc
Original Assignee
Wily Technology Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Wily Technology Inc filed Critical Wily Technology Inc
Priority to US09/839,056 priority Critical patent/US20020007482A1/en
Publication of US20020007482A1 publication Critical patent/US20020007482A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/445Program loading or initiating
    • G06F9/44521Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/448Execution paradigms, e.g. implementations of programming paradigms
    • G06F9/4488Object-oriented
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
    • G06F9/45529Embedded in an application, e.g. JavaScript in a Web browser

Definitions

  • the present invention is directed to a system for modifying object oriented code.
  • 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.
  • 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.
  • 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.
  • 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.
  • certain people have special needs, such as color blind people may prefer gray scale user interfaces rather than color interfaces.
  • 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.
  • a local area network e.g. an office
  • 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.
  • 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.
  • SOM System Object Model
  • IBM System Object Model
  • 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.
  • any changes made are not permanent.
  • the user is left with the original program rather than a modified version that can be shipped to other users.
  • 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.
  • the present invention 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.
  • 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.
  • 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.
  • 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.
  • the code modifier described below can be implemented in software and run on a general purpose computer.
  • the invention can be implemented in specific hardware, or a combination of specific hardware and software, designed to carry out the methods described herein.
  • 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.
  • 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.
  • 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.
  • FIG. 1 is a block diagram of the code modifier of the present invention.
  • FIG. 2 is a flow chart explaining the steps of using the code modifier.
  • FIG. 3 is a flow chart explaining the operation of the code modifier.
  • FIG. 4 is a flow chart explaining the process class step 42 of FIG. 3.
  • FIG. 5 depicts a symbolic representation of the class data structure.
  • FIG. 6 is a flow chart explaining the substitute class step 84 of FIG. 4.
  • FIG. 7 is a flow chart explaining the proxy class step 92 of FIG. 4.
  • FIG. 8 is a flow chart explaining the substitute static field step 98 of FIG. 4.
  • FIG. 9 is a block diagram of one exemplar hardware platform for implementing the present invention.
  • 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:
  • Substitute Class ⁇ original class> ⁇ new class>.
  • the substitute class rule instructs code modifier 10 to change the code that allocates an object of the ⁇ original class> to code that allocates the object to be of the ⁇ new class>, where the ⁇ new class> extends (or is a subclass of) the ⁇ original class>.
  • 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.
  • the allocation of an object includes two steps: (1) creating the object and (2) invoking the object's constructor.
  • An object's constructor is a method that is invoked once to make the object useable.
  • the constructor is the method ⁇ init>.
  • the second type of rule is the proxy class rule which has the format:
  • Proxy Class ⁇ original class> ⁇ proxy Allocator Class>.
  • the Proxy class rule instructs code modifier 10 to change the code that allocates an object of ⁇ original class> to code that calls a static method in ⁇ proxy Allocator Class>.
  • the static method will allocate the object of ⁇ original class> and must accept the same arguments as the constructor.
  • the ⁇ original class> 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.
  • the third rule is a substitute static field rule which has the following format:
  • Substitute Static Field ⁇ original static field> ⁇ new static field>.
  • the substitute static field rule directs code modifier 10 to substitute the ⁇ new static field> for the ⁇ original static field>.
  • 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.
  • 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.
  • FIG. 2 is a flow chart which explains how code modifier 10 is used.
  • 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.
  • 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.
  • the user creates a rule or set of rules to implement the change.
  • 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.
  • FIG. 3 is a flow chart explaining the operation of code modifier 10 .
  • code modifier 10 loads the rules into a data structure. The exact form of the data structure is not important.
  • code modifier 10 processes a class from the set of program classes using the rules and set of additional classes.
  • 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.
  • the ⁇ original class> referenced in the rules is from the set of program classes and the ⁇ new class> is from the set of additional classes, such an arrangement is not required.
  • both the ⁇ new class> and the ⁇ original class> can be from the set of program classes.
  • Other variations can also exist.
  • FIG. 4 is a flow chart explaining the details of step 42 of FIG. 3.
  • code modifier 10 loads a class into a class data structure.
  • 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 .
  • 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 .
  • 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.
  • 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.
  • FIG. 5 is a symbolic representation of the class data structure which holds the code for a class.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • 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.
  • CONSTANT_Class_info structure is used to represent a class or an interface: CONSTANT_Class_info ⁇ u1 tag; u2 name index; ⁇
  • 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's internal form.
  • the values u1, u2 and u4 represent an unsigned one, two or four byte quantities, respectively.
  • 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.
  • 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.
  • CONSTANT_String_info structure is used to represent constant objects of the type java.lang.String: CONSTANT_String_info ⁇ u1 tag; u2 string_index; ⁇
  • 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.
  • 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; ⁇
  • 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.
  • 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.
  • CONSTANT_Utf8_info structure is used to represent constant string values: CONSTANT_Utf8_info ⁇ u1 tag; u2 length; bytes [length]; ⁇
  • 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.
  • 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]; ⁇
  • 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.
  • 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.
  • method_info ⁇ u2 access_flags; u2 name_index; u2 descriptor_index; u2 attributes_count; attribute_info attributes [attributes_count]; ⁇
  • 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 ⁇ init> or ⁇ clinit>, 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]; ⁇
  • 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.
  • FIG. 6 is a flow chart which explains the method of the substitute class step 84 of FIG. 4.
  • code modifier 10 looks through the constant pool for an entry referencing the ⁇ original class> to be substituted for.
  • 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.
  • 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.
  • 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 ).
  • 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 ).
  • the system 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 ⁇ 8)
  • the item at the index in the constant pool must be a CONSTANT_Class_info structure.
  • 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 ).
  • 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 .
  • 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 ⁇ 8)
  • 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.
  • 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 .
  • 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 .
  • FIG. 7 is a flow chart which explains proxy class step 92 of FIG. 4.
  • 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 ).
  • 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.
  • 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.
  • 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 ).
  • 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 .
  • 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 .
  • 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 .
  • 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 .
  • 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 ).
  • 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.
  • code modifier 10 adds to the constant pool a CONSTANT_Utf8_info structure storing the name of the new static field.
  • code modifier 10 adds a CONSTANT_Utf8_info structure storing the field descriptor for the new static field.
  • 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 .
  • 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 .
  • 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 .
  • ExampleAppletjava 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.
  • 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 “ ⁇ Class Java.lang.String>.” That identified class is the class pointed to by the index (identified by the CONSTANT_Class_info structure).
  • SampleApplet extends java.applet.Applet /* ACC_SUPER bit set */ ⁇ public SampleApplet(); ⁇ Method SampleApplet() 0 aload_0 1 invokespecial #9 ⁇ Method java.applet.Applet()> 4 new #8 ⁇ Class java.lang.String> 7 dup 8 ldc #1 ⁇ String “Simple Applet”> 10 invokespecial #11 ⁇ Method java.lang.String(java.lang.
  • 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.
  • # Replacement classes e.g., RedButton
  • SubstituteClass java/awt/Button RedButton
  • SubstituteStaticField java.awt.Color.yellow java.awt.Color.green
  • ProxyClass java/lang/String UpperCaseProxyString
  • RedButton.java 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); ⁇ ⁇
  • 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.
  • SampleApplet extends java.applet.Applet /* ACC_SUPER bit set */ ⁇ public SampleApplet(); ⁇ Method SampleApplet() 0 aload_0 1 invokespecial #9 ⁇ Method java.applet.Applet()> 4 nop 5 nop 6 nop 7 nop 8 ldc #1 ⁇ String “Simple Applet”> 10 invokestatic #52 ⁇ Method java.lang.String createProxyObject(java.lang.String)> 13 astore_1 14 aload_0 15 new #45 ⁇ Class RedButton> 18 dup 19 aload_1 20 invokespecial #46 ⁇ Method RedButton(java.lang.String)> 23 invokevirtual #12 ⁇ Method java.awt.Component add(java.awt.Component)> 26 pop 27 aload_0 28 getstatic #14 ⁇ Field java.awt.Color
  • 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.
  • DRAM dynamic random access memory
  • 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 .
  • the components in computer system 600 are shown in FIG. 9 as being connected via a single bus 628 .
  • computer system 600 may be connected through one or more data transport means.
  • 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 .
  • mass storage device 16 stores the system software implementing code modifier 10 for purposes of loading to main memory 614 .
  • 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 .
  • 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 .
  • peripheral device(s) 618 may include a network interface card for interfacing computer system 600 to a network, a modem, etc.
  • 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.
  • 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.

Abstract

The system receives three sets of inputs: program class definitions, a set of rules, and additional class definitions to be merged with the program 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 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 separately reads each of the original class definitions into a class data structure and performs the modifications to the class data structure according to the set of rules. The resulting class data structure is written to an output stream.

Description

    BACKGROUND OF THE INVENTION
  • 1. Field of the Invention [0001]
  • The present invention is directed to a system for modifying object oriented code. [0002]
  • 2. Description of the Related Art [0003]
  • 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. [0004]
  • 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. [0005]
  • 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. [0006]
  • 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. [0007]
  • 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. [0008]
  • 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. [0009]
  • 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. [0010]
  • SUMMARY OF INVENTION
  • 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. [0011]
  • 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. [0012]
  • 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. [0013]
  • 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.[0014]
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 is a block diagram of the code modifier of the present invention. [0015]
  • FIG. 2 is a flow chart explaining the steps of using the code modifier. [0016]
  • FIG. 3 is a flow chart explaining the operation of the code modifier. [0017]
  • FIG. 4 is a flow chart explaining the [0018] process class step 42 of FIG. 3.
  • FIG. 5 depicts a symbolic representation of the class data structure. [0019]
  • FIG. 6 is a flow chart explaining the [0020] substitute class step 84 of FIG. 4.
  • FIG. 7 is a flow chart explaining the [0021] proxy class step 92 of FIG. 4.
  • FIG. 8 is a flow chart explaining the substitute [0022] static field step 98 of FIG. 4.
  • FIG. 9 is a block diagram of one exemplar hardware platform for implementing the present invention.[0023]
  • DETAILED DESCRIPTION
  • FIG. 1 shows a block diagram of the [0024] 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:
  • Substitute Class: <original class> <new class>. [0025]
  • The substitute class rule instructs [0026] code modifier 10 to change the code that allocates an object of the <original class> to code that allocates the object to be of the <new class>, where the <new class> extends (or is a subclass of) the <original class>. 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.
  • For Java code, the allocation of an object includes two steps: (1) creating the object and (2) invoking the object's constructor. An object's constructor is a method that is invoked once to make the object useable. For Java code, the constructor is the method <init>. 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. [0027]
  • The second type of rule is the proxy class rule which has the format: [0028]
  • Proxy Class: <original class> <proxy Allocator Class>. [0029]
  • The Proxy class rule instructs [0030] code modifier 10 to change the code that allocates an object of <original class> to code that calls a static method in <proxy Allocator Class>. The static method will allocate the object of <original class> and must accept the same arguments as the constructor. In one embodiment the <original class> 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.
  • The third rule is a substitute static field rule which has the following format: [0031]
  • Substitute Static Field: <original static field> <new static field>. [0032]
  • The substitute static field rule directs [0033] code modifier 10 to substitute the <new static field> for the <original static field>. 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.
  • The third input to code [0034] 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.
  • FIG. 2 is a flow chart which explains how [0035] 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.
  • FIG. 3 is a flow chart explaining the operation of [0036] 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 <original class> referenced in the rules is from the set of program classes and the <new class> is from the set of additional classes, such an arrangement is not required. For example, both the <new class> and the <original class> can be from the set of program classes. Other variations can also exist.
  • FIG. 4 is a flow chart explaining the details of [0037] 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.
  • 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. [0038] 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.
  • The value of [0039] 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.
  • The value of interfaces count [0040] 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<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.
  • The value of methods count [0041] 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.
  • The value of the attributes count [0042] 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.
  • All constant pool entries have the following general format: [0043]
    cp_info {
    tag;
    info[];
    }
  • 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. [0044]
  • The CONSTANT_Class_info structure is used to represent a class or an interface: [0045]
    CONSTANT_Class_info {
    u1 tag;
    u2 name index;
    }
  • 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's internal form. The values u1, u2 and u4 represent an unsigned one, two or four byte quantities, respectively. [0046]
  • Fields, methods, and interface methods are represented by similar structures: [0047]
    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;
    }
  • 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. [0048]
  • 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. [0049]
  • 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. [0050]
  • The CONSTANT_String_info structure is used to represent constant objects of the type java.lang.String: [0051]
    CONSTANT_String_info {
    u1 tag;
    u2 string_index;
    }
  • 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. [0052]
  • The CONSTANT_Integer_info and CONSTANT_Float_info structures represent four-byte numeric (int and float) constants: [0053]
    CONSTANT_Integer_info {
    u1 tag;
    u4 bytes;
    }
    CONSTANT_Float_info {
    u1 tag;
    u4 bytes;
    }
  • 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 [0054] 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.
  • The CONSTANT_Long_info and CONSTANT_Double_info represent eight-byte numeric (long and double) constants: [0055]
    CONSTANT_Long_info {
    u1 tag;
    u4 high bytes;
    u4 low bytes;
    }
    CONSTANT_Double_info {
    u1 tag;
    u4 high bytes;
    u4 low bytes;
    }
  • 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. [0056]
  • 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<<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. [0057]
  • The CONSTANT_NameAndType_info structure is used to represent a field or method, without indicating which class or interface type it belongs to: [0058]
    CONSTANT_NameAndType_info {
    u1 tag;
    u2 name_index;
    u2 descriptor_index
    }
  • 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. [0059]
  • The CONSTANT_Utf8_info structure is used to represent constant string values: [0060]
    CONSTANT_Utf8_info {
    u1 tag;
    u2 length;
    bytes [length];
    }
  • 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)[0061] 0 or (byte)0xf0-(byte)0xff.
  • Each field (see FIG. 5—fields [0062] 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];
    }
  • 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. [0063]
  • 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. [0064]
  • Each method (see FIG. 5—methods [0065] 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];
    }
  • 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 <init> or <clinit>, 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. [0066]
    Attributes have the following general format:
    attribute_info {
    u2 attribute_name_index;
    u4 attribute_length;
    u1 info [attribute_length];
    }
  • 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. [0067]
  • FIG. 6 is a flow chart which explains the method of the [0068] 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 <original class> 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.
  • After making the additions to the constant pool, the system will test whether the superclass needs to be changed (step [0069] 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 indexbyte1 indexbyte2. The unsigned indexbyte1 and indexbyte2 are used to construct an index into the constant pool where the value of the index is (indexbyte1<<8)|indexbyte2. The item at the index in the constant pool must be a CONSTANT_Class_info structure.
  • If the next instruction is a “new” (step [0070] 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.
  • If (in step [0071] 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 indexbyte1 indexbyte2. The unsigned indexbyte1 and indexbyte2 are used to construct an index into the constant pool of the current class, where the index is (indexbyte1<<8)|indexbyte2. 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.
  • FIG. 7 is a flow chart which explains [0072] 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.
  • If, in [0073] 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.
  • FIG. 8 is a flow chart which explains the method of the substitute [0074] 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.
  • To better explain the principals discussed above, consider the following example. Suppose a user of [0075] 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'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's background color to yellow
    setBackground (Color.yellow);
    }
    }
  • 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 “<Class Java.lang.String>.” That identified class is the class pointed to by the index (identified by the CONSTANT_Class_info structure). [0076]
    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 <Method java.applet.Applet()>
     4 new #8 <Class java.lang.String>
     7 dup
     8 ldc #1 <String “Simple Applet”>
    10 invokespecial #11 <Method java.lang.String(java.lang.
      String)>
    13 astore_1
    14 aload_0
    15 new #4 <Class java.awt.Button>
    18 dup
    19 aload_1
    20 invokespecial #10 <Method java.awt.Button(java.lang.String)>
    23 invokevirtual #12 <Method java.awt.Component
      add(java.awt.Component)>
    26 pop
    27 aload_0
    28 getstatic #14 <Field java.awt.Color yellow>
    31 invokevirtual #13 <Method void setBackground(java.awt.Color)>
    34 return
  • Suppose, for this example, that the user of [0077] 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.
  • Sample.di [0078]
  • #[0079]
  • # Rules file [0080]
  • #[0081]
  • # This file specifies how the code modifier [0082]
  • # will modify the class inheritance structure [0083]
  • # of its target class files. [0084]
  • #[0085]
  • # Replacement classes (e.g., RedButton) are supplied in [0086]
  • # the following file [0087]
  • MergeFile: mergeclasses.jar [0088]
  • # replace all allocations. and subclassing of java/awt/Button with RedButton [0089]
  • SubstituteClass: java/awt/Button RedButton [0090]
  • # change all references to the color “yellow” to be the color “green”[0091]
  • SubstituteStaticField: java.awt.Color.yellow java.awt.Color.green [0092]
  • # use a proxy constructor for all allocations of java/lang/String [0093]
  • ProxyClass: java/lang/String UpperCaseProxyString [0094]
  • 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 [0095] 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);
    }
    }
  • 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 [0096] 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 ();
    }
    }
  • The code from UpperCaseProxyString.java and RedButton.java, Sample.di (the rules) and the code represented by Before.txt would be inputs to code [0097] 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 <Method java.applet.Applet()>
     4 nop
     5 nop
     6 nop
     7 nop
     8 ldc #1 <String “Simple Applet”>
    10 invokestatic #52 <Method java.lang.String
      createProxyObject(java.lang.String)>
    13 astore_1
    14 aload_0
    15 new #45 <Class RedButton>
    18 dup
    19 aload_1
    20 invokespecial #46 <Method RedButton(java.lang.String)>
    23 invokevirtual #12 <Method java.awt.Component
      add(java.awt.Component)>
    26 pop
    27 aload_0
    28 getstatic #14 <Field java.awt.Color green>
    31 invokevirtual #13 <Method void setBackground(java.awt.Color)>
    34 return
  • 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 ([0098] 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.
  • FIG. 9 illustrates a high level block diagram of a general purpose computer system which can be used to run the software that implements [0099] 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.
  • Portable [0101] 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.
  • Input device(s) [0102] 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.
  • 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. [0103]
  • 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. [0104]

Claims (38)

I claim:
1. A method of modifying object oriented code, comprising the steps of:
reading a rule defining a change to object code, said object code including a definition of an object oriented class;
modifying said object code based on said rule; and
writing said modified object code.
2. A method according to claim 1, wherein said step of modifying includes:
changing first code that allocates a first object of a first class to second code that allocates said first object based on a second class.
3. A method according to claim 2, wherein:
said second class extends said first class.
4. A method according to claim 3, further including the step of:
merging said second class with said first class.
5. A method according to claim 3, wherein said step of modifying includes the steps of:
looking for a creation instruction in said which includes a first reference to said first class;
changing said first reference to refer to said second class, if said step of looking for said creation instruction found said creation instruction;
looking for a first instruction which invokes a constructor for said first class; and
changing said first instruction to a second instruction which invokes a constructor for said second class, if said step of looking for said first instruction found said first instruction.
6. A method according to claim 5, further including the step of:
reading said object code into a data structure, said data structure includes a table of constant information, said step of changing said first reference changes an index into said table of constant information.
7. A method according to claim 6, wherein said step of modifying further includes the steps of:
searching said data structure for a reference to said first class; and
adding to said data structure a reference to said second class if said step of searching finds said reference to said first class;
said step of changing said first reference changes an index which points to a reference to said first class to an index which points to a reference to said second class;
said step of changing said first instruction to a second instruction includes the step of adding a reference to said constructor for said second class, said second instruction including an index pointing to said reference to said constructor for said second class.
8. A method according to claim 1, wherein:
said object oriented class has a superclass;
said object code including code identifying said superclass; and
said step of modifying includes changing said identification of said superclass from a first class to a second class, said second class extends said first class.
9. A method according to claim 1, wherein said step of modifying includes:
changing first code that allocates a first object of a first class to second code that invokes a static method that allocates said first object of said first class.
10. A method according to claim 9, wherein:
said first class is a final class.
11. A method according to claim 9, wherein said step of modifying includes the steps of:
looking for a creation instruction which includes a first reference to said first class; and
changing said creation instruction to a nop.
12. A method according to claim 9, further including the step of:
reading said object code into a data structure, said data structure includes a table of constant information;
said step of modifying further includes the steps of:
searching said data structure for a reference to said first class,
adding to said data structure a reference to said second class if said step of searching finds said reference to said first class,
searching said data structure for a first instruction that invokes a constructor of said first class,
adding to said table a reference to said static method, and
changing said first instruction to a second instruction, said second instruction invokes said static method.
13. A method according to claim 1, wherein said step of modifying includes:
changing a reference to a first static field to a reference to a second static field.
14. A method according to claim 13, further including the step of:
reading said object code into a data structure, said data structure includes a table of constant information.
15. A method according to claim 14, wherein said step of changing a reference to a first static field includes:
searching said table for a first reference to said first static field;
adding to said table a second reference to said second static field; and
changing a third reference to a fourth reference, said third reference points to said first reference and said fourth reference points to said second reference.
16. A method according to claim 1, further including the step of:
reading said object code into a data structure, said step of modifying includes modifying said data structure.
17. A method according to claim 1, wherein:
said object code is java object code.
18. A method according to claim 1, wherein:
said object code includes definitions of a plurality of object oriented classes; and
said steps of modifying and writing are performed for each of said object oriented classes.
19. A method of modifying object oriented code, comprising the steps of:
reading a rule defining a substitution of a new class for an original class;
reviewing an input class definition; and
if said step of reviewing finds an allocation of an object based on said original class, changing said allocation of said object to be based on said new class.
20. A method according to claim 19, wherein:
said new class extends said original class.
21. A method according to claim 19, further including the steps of:
reading said input class definition into a data structure, said data structure including a reference to said original class; and
adding to said data structure a reference to said new class, said step of changing said allocation of said object includes changing an index to said reference to said original class to be an index to said reference to said replacement class.
22. A method according to claim 19, wherein:
said input class has a superclass;
said input class definition including code identifying said superclass; and
said method of modifying object oriented code further includes the step of changing said identification of said superclass from said original class to said new class if said input class is a subclass of said original class.
23. A method according to claim 19, wherein:
said object oriented code is java object code.
24. A method according to claim 19, further including the steps of:
reading a rule defining a proxy of a final class by a proxy class;
reviewing said input class definition; and
if said step of reviewing finds an allocation of an object based on said final class, changing said allocation of said object based on said final class to be an invocation of a static method in said proxy class, said static method allocating said object based on said final class.
25. A method according to claim 19, further including the steps of:
receiving a set of rules;
receiving a set of additional classes including said new class;
receiving a set of program classes including said input class; and
writing at least a portion of said input class to a stream after said step of changing said allocation.
26. A processor readable storage medium having processor readable code embodied on said processor readable storage medium, said processor readable code for programming a processor to perform a method comprising the steps of:
reading a rule defining a change to object code, said object code defining an object oriented class; and
modifying said object code based on said rule.
27. A processor readable storage medium according to claim 26, wherein said step of modifying includes:
changing first code that allocates a first object of a first class to second code that allocates said first object based on a second class, said second class extends said first class.
28. A processor readable storage medium according to claim 26, wherein said step of modifying includes the steps of:
looking for a creation instruction which includes a first reference to said first class;
changing said first reference to refer to said second class, if said step of looking for said creation instruction found said creation instruction;
looking for a first instruction which invokes a constructor for said first class; and
changing said first instruction to a second instruction which invokes a constructor for said second class, if said step of looking for said first instruction found said first instruction.
29. A processor readable storage medium according to claim 26, wherein:
said object oriented class has a superclass;
said object code including code identifying said superclass; and
said step of modifying includes changing said identification of said superclass from a first class to a second class, said second class extends said first class.
30. A processor readable storage medium according to claim 26, wherein said step of modifying includes:
changing first code that allocates a first object of a first class to second code that calls a static method that allocates said first object of said first class, said first class is a final class.
31. A processor readable storage medium according to claim 26, wherein said step of modifying includes:
changing a reference to a first static field to a reference to a second static field.
32. A processor readable storage medium according to claim 26 wherein:
said object code is java object code.
33. An apparatus capable of modifying object oriented code, comprising:
one or more input devices;
one or more output devices;
a processor in communication with said input device and said output device;
a storage unit in communication with said processor, said storage device adapted to store program code, said program code programs said processor to perform the step of:
reading a rule defining a change to object code, said object code defining an object oriented class, and
modifying said object code based on said rule.
34. An apparatus according to claim 33, wherein said step of modifying includes:
changing first code that allocates a first object of a first class to second code that allocates said first object of a second class, said second class extends said first class.
35. An apparatus according to claim 33, wherein:
said object oriented class has a superclass;
said object code including code identifying said superclass; and
said step of modifying includes changing said identification of said superclass from a first class to a second class, said second class extends said first class.
36. An apparatus according to claim 33, wherein said step of modifying includes:
changing first code that allocates a first object of a first class to second code that calls a static method that allocates said first object of said first class, said first class is a final class.
37. An apparatus according to claim 33, wherein said step of modifying includes:
changing a reference to a first static field to a reference to a second static field.
38. An apparatus according to claim 33, wherein:
said object code is java object code.
US09/839,056 1998-08-20 2001-04-20 System for modifying object oriented code Abandoned US20020007482A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US09/839,056 US20020007482A1 (en) 1998-08-20 2001-04-20 System for modifying object oriented code

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/137,666 US6260187B1 (en) 1998-08-20 1998-08-20 System for modifying object oriented code
US09/839,056 US20020007482A1 (en) 1998-08-20 2001-04-20 System for modifying object oriented code

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US09/137,666 Continuation US6260187B1 (en) 1998-08-20 1998-08-20 System for modifying object oriented code

Publications (1)

Publication Number Publication Date
US20020007482A1 true US20020007482A1 (en) 2002-01-17

Family

ID=22478519

Family Applications (2)

Application Number Title Priority Date Filing Date
US09/137,666 Expired - Lifetime US6260187B1 (en) 1998-08-20 1998-08-20 System for modifying object oriented code
US09/839,056 Abandoned US20020007482A1 (en) 1998-08-20 2001-04-20 System for modifying object oriented code

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US09/137,666 Expired - Lifetime US6260187B1 (en) 1998-08-20 1998-08-20 System for modifying object oriented code

Country Status (1)

Country Link
US (2) US6260187B1 (en)

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040205710A1 (en) * 2000-02-21 2004-10-14 Masaki Kawai Program generation apparatus
WO2004097603A1 (en) * 2003-05-02 2004-11-11 Bitarts Limited Protecting a java application
US20050209863A1 (en) * 2004-03-05 2005-09-22 International Business Machines Corporation Reducing the run-time cost of invoking a server page
US20110083162A1 (en) * 2009-10-01 2011-04-07 Nokia Corporation Method and apparatus for providing context access with property and interface obfuscation
US20110178971A1 (en) * 2010-01-15 2011-07-21 International Business Machines Corporation Portable data management
US8666998B2 (en) 2010-09-14 2014-03-04 International Business Machines Corporation Handling data sets
US8898104B2 (en) 2011-07-26 2014-11-25 International Business Machines Corporation Auto-mapping between source and target models using statistical and ontology techniques
US8949166B2 (en) 2010-12-16 2015-02-03 International Business Machines Corporation Creating and processing a data rule for data quality
US20160323396A1 (en) * 2015-04-30 2016-11-03 AppDynamics, Inc. Agent Asynchronous Transaction Monitor
CN106843912A (en) * 2017-03-22 2017-06-13 武汉斗鱼网络科技有限公司 Page info acquisition methods and device
US10165074B2 (en) * 2015-04-30 2018-12-25 Cisco Technology, Inc. Asynchronous custom exit points
US11263110B1 (en) * 2015-12-31 2022-03-01 EMC IP Holding Company LLC Inter-object validation system and method for the objects of a test system

Families Citing this family (117)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0825506B1 (en) 1996-08-20 2013-03-06 Invensys Systems, Inc. Methods and apparatus for remote process control
US5966702A (en) * 1997-10-31 1999-10-12 Sun Microsystems, Inc. Method and apparatus for pre-processing and packaging class files
US6393491B1 (en) 1999-04-26 2002-05-21 Sun Microsystems, Inc. Method and apparatus for dispatch table construction
US7089530B1 (en) 1999-05-17 2006-08-08 Invensys Systems, Inc. Process control configuration system with connection validation and configuration
WO2000070531A2 (en) 1999-05-17 2000-11-23 The Foxboro Company Methods and apparatus for control configuration
US6788980B1 (en) 1999-06-11 2004-09-07 Invensys Systems, Inc. Methods and apparatus for control using control devices that provide a virtual machine environment and that communicate via an IP network
US6968549B1 (en) 1999-07-02 2005-11-22 Beryl Technical Assays Llc Method and system for dynamically loading data structures into memory with global constant pool
US7150005B2 (en) * 1999-07-02 2006-12-12 Beryl Technical Assays, Llc Method and system for global constant management for memory
US6510352B1 (en) * 1999-07-29 2003-01-21 The Foxboro Company Methods and apparatus for object-based process control
US6463578B1 (en) * 1999-11-23 2002-10-08 International Business Machines Corporation Systems, methods and computer program products for debugging java server page files using compiled java class file modifications
US6550058B1 (en) * 2000-02-03 2003-04-15 International Business Machines Corporation Stack clearing device and method
GB0004090D0 (en) * 2000-02-22 2000-04-12 Innovation Venture Ltd Application programming system and method of operation thereof
JP3555858B2 (en) * 2000-03-23 2004-08-18 インターナショナル・ビジネス・マシーンズ・コーポレーション Program editing method, single packaging system, program development system, program identification information addition system, and storage medium
US20020087958A1 (en) * 2000-04-20 2002-07-04 International Business Machines Corporation Method and apparatus of transforming a class
US7774455B1 (en) * 2000-09-26 2010-08-10 Juniper Networks, Inc. Method and system for providing secure access to private networks
US7085817B1 (en) * 2000-09-26 2006-08-01 Juniper Networks, Inc. Method and system for modifying requests for remote resources
US6996813B1 (en) 2000-10-31 2006-02-07 Sun Microsystems, Inc. Frameworks for loading and execution of object-based programs
TW584801B (en) * 2000-12-11 2004-04-21 Ntt Docomo Inc Terminal and repeater
US20020078106A1 (en) * 2000-12-18 2002-06-20 Carew David John Method and apparatus to spell check displayable text in computer source code
US7512935B1 (en) * 2001-02-28 2009-03-31 Computer Associates Think, Inc. Adding functionality to existing code at exits
AU2002250146A1 (en) * 2001-02-28 2002-09-19 Wily Technology, Inc. Detecting a stalled routine
US7020874B2 (en) * 2001-03-26 2006-03-28 Sun Microsystems, Inc. Techniques for loading class files into virtual machines
US7096466B2 (en) 2001-03-26 2006-08-22 Sun Microsystems, Inc. Loading attribute for partial loading of class files into virtual machines
US7543288B2 (en) 2001-03-27 2009-06-02 Sun Microsystems, Inc. Reduced instruction set for Java virtual machines
US6957428B2 (en) 2001-03-27 2005-10-18 Sun Microsystems, Inc. Enhanced virtual machine instructions
DE60237718D1 (en) * 2001-05-30 2010-10-28 Research In Motion Ltd SYSTEM FOR PROCESSING AN APPLICATION FOR A MOBILE COMMUNICATION DEVICE
US6836884B1 (en) * 2001-06-04 2004-12-28 Microsoft Corporation Method and system for editing software programs
US6934726B2 (en) * 2001-06-20 2005-08-23 Sun Microsystems, Inc. Storing and retrieving of field descriptors in Java computing environments
US7757225B2 (en) * 2001-06-29 2010-07-13 Microsoft Corporation Linktime recognition of alternative implementations of programmed functionality
US6988261B2 (en) * 2001-08-24 2006-01-17 Sun Microsystems, Inc. Frameworks for generation of Java macro instructions in Java computing environments
US7228533B2 (en) * 2001-08-24 2007-06-05 Sun Microsystems, Inc. Frameworks for generation of Java macro instructions for performing programming loops
US7039904B2 (en) * 2001-08-24 2006-05-02 Sun Microsystems, Inc. Frameworks for generation of Java macro instructions for storing values into local variables
US7058934B2 (en) * 2001-08-24 2006-06-06 Sun Microsystems, Inc. Frameworks for generation of Java macro instructions for instantiating Java objects
US7028225B2 (en) * 2001-09-25 2006-04-11 Path Communications, Inc. Application manager for monitoring and recovery of software based application processes
US7162710B1 (en) * 2001-11-01 2007-01-09 Microsoft Corporation Dynamic modifications to a heterogeneous program in a distributed environment
WO2003105010A1 (en) 2002-06-06 2003-12-18 Neoteris, Inc. Method and system for providing secure access to private networks
US7162712B2 (en) * 2002-06-26 2007-01-09 Sun Microsystems, Inc. Method and apparatus for creating string objects in a programming language
US6904516B2 (en) * 2002-07-17 2005-06-07 Sun Microsystems, Inc. Mechanism for enabling efficient execution of an instruction
US7051230B2 (en) * 2002-07-18 2006-05-23 International Business Machines Corporation Method and system for allowing customization of remote data collection in the event of a system error
GB0218680D0 (en) * 2002-08-10 2002-09-18 Ibm Method and system for modifying a class file to monitor data flow
US7870431B2 (en) * 2002-10-18 2011-01-11 Computer Associates Think, Inc. Transaction tracer
US7096463B2 (en) * 2002-11-20 2006-08-22 Hewlett-Packard Development Company, Lp. System and apparatus for dynamically upgrading concentrated executable computer software code
US7093245B2 (en) * 2002-11-20 2006-08-15 Hewlett-Packard Development Company, L.P. System and apparatus for upgrading concentrated executable computer software code without reconcentration
JP3862652B2 (en) * 2002-12-10 2006-12-27 キヤノン株式会社 Printing control method and information processing apparatus
US20040123279A1 (en) * 2002-12-18 2004-06-24 International Business Machines Corporation Method and system for auto-instrumenting java applications through probe injection
US7269824B2 (en) * 2003-02-13 2007-09-11 Path Reliability, Inc. Software behavior pattern recognition and analysis
US7953765B2 (en) * 2003-07-11 2011-05-31 Computer Associates Think, Inc. System and method for storing metrics in a database
DE10335989B4 (en) * 2003-08-01 2019-07-11 Kw-Software Gmbh Online changes to CIL code programs for industrial automation
US7484209B2 (en) 2003-08-12 2009-01-27 Hewlett-Packard Development Company, L.P. Instrumenting java code by modifying bytecodes
US7496903B2 (en) 2003-08-12 2009-02-24 Hewlett-Packard Development Company, L.P. Synthesizing application response measurement (ARM) instrumentation
US20050039171A1 (en) * 2003-08-12 2005-02-17 Avakian Arra E. Using interceptors and out-of-band data to monitor the performance of Java 2 enterprise edition (J2EE) applications
US7437734B2 (en) * 2003-08-12 2008-10-14 Hewlett-Packard Development Company, L.P. Propagating web transaction context into common object model (COM) business logic components
US7493622B2 (en) * 2003-08-12 2009-02-17 Hewlett-Packard Development Company, L.P. Use of thread-local storage to propagate application context in Java 2 enterprise edition (J2EE) applications
CA2452077A1 (en) * 2003-12-03 2005-06-03 Daniel A. Rose Verification of stream oriented locale files
FR2864650B1 (en) * 2003-12-24 2006-03-24 Trusted Logic METHOD FOR UPDATING APPLICATIONS FOR A CHIP CARD
US7895580B1 (en) 2003-12-30 2011-02-22 Sap Ag Application tracing service employing different levels of precision for modifying bytecode
US7725572B1 (en) 2003-12-30 2010-05-25 Sap Ag Notification architecture and method employed within a clustered node configuration
US7822826B1 (en) 2003-12-30 2010-10-26 Sap Ag Deployment of a web service
US7367025B1 (en) 2003-12-30 2008-04-29 Sap Ag Byte code modification for testing, debugging and/or monitoring of virtual machine based software
US7644395B1 (en) 2003-12-30 2010-01-05 Sap Ag System and method employing bytecode modification techniques for tracing services within an application server
US7756968B1 (en) 2003-12-30 2010-07-13 Sap Ag Method and system for employing a hierarchical monitor tree for monitoring system resources in a data processing environment
US7836438B1 (en) * 2003-12-30 2010-11-16 Sap Ag Modified classfile registration with a dispatch unit that is responsible for dispatching invocations during runtime execution of modified bytecode
US7506315B1 (en) 2003-12-30 2009-03-17 Sap Ag System and method combining application tracing and distributed statistical records
US7426723B1 (en) 2003-12-30 2008-09-16 Sap Ag Classfile conversion into an organization of objects, and modification thereof, to effect bytecode modification
US7941521B1 (en) 2003-12-30 2011-05-10 Sap Ag Multi-service management architecture employed within a clustered node configuration
US7707557B1 (en) * 2003-12-30 2010-04-27 Sap Ag Execution of modified byte code for debugging, testing and/or monitoring of object oriented software
US7743367B1 (en) 2003-12-30 2010-06-22 Sap Ag Registration method for supporting bytecode modification
US7761923B2 (en) 2004-03-01 2010-07-20 Invensys Systems, Inc. Process control methods and apparatus for intrusion detection, protection and network hardening
US7721266B2 (en) * 2004-03-26 2010-05-18 Sap Ag Unified logging service with a logging formatter
US20050216585A1 (en) * 2004-03-26 2005-09-29 Tsvetelina Todorova Monitor viewer for an enterprise network monitoring system
US7526550B2 (en) * 2004-03-26 2009-04-28 Sap Ag Unified logging service with a log viewer
US7373516B2 (en) 2004-08-19 2008-05-13 International Business Machines Corporation Systems and methods of securing resources through passwords
US7788226B2 (en) 2004-12-30 2010-08-31 Sap Ag Monitoring availability of applications
US7783679B2 (en) * 2005-01-12 2010-08-24 Computer Associates Think, Inc. Efficient processing of time series data
US7506334B2 (en) * 2005-02-25 2009-03-17 Microsoft Corporation Common, multi-version interface that allows a distributed sybsystem to communicate with multiple versions of the distributed subsystem
US7434206B2 (en) * 2005-03-10 2008-10-07 Hewlett-Packard Development Company, L.P. Identifying memory leaks in computer systems
US7810075B2 (en) * 2005-04-29 2010-10-05 Sap Ag Common trace files
US20070094281A1 (en) * 2005-10-26 2007-04-26 Malloy Michael G Application portfolio assessment tool
WO2007123753A2 (en) 2006-03-30 2007-11-01 Invensys Systems, Inc. Digital data processing apparatus and methods for improving plant performance
US8656006B2 (en) * 2006-05-11 2014-02-18 Ca, Inc. Integrating traffic monitoring data and application runtime data
US7805510B2 (en) * 2006-05-11 2010-09-28 Computer Associates Think, Inc. Hierarchy for characterizing interactions with an application
JP2007316905A (en) * 2006-05-25 2007-12-06 Hitachi Ltd Computer system and method for monitoring application program
US8234623B2 (en) 2006-09-11 2012-07-31 The Mathworks, Inc. System and method for using stream objects to perform stream processing in a text-based computing environment
US9009680B2 (en) * 2006-11-30 2015-04-14 Ca, Inc. Selecting instrumentation points for an application
US20080148242A1 (en) * 2006-12-18 2008-06-19 Computer Associates Think, Inc. Optimizing an interaction model for an application
US7689610B2 (en) * 2006-12-01 2010-03-30 Computer Associates Think, Inc. Automated grouping of messages provided to an application using string similarity analysis
US7917911B2 (en) * 2006-12-01 2011-03-29 Computer Associates Think, Inc. Automated grouping of messages provided to an application using execution path similarity analysis
EP2137622B1 (en) * 2007-04-18 2018-07-11 Siemens Aktiengesellschaft Method and data processing system for computer-assisted performance analysis of a data processing system
US8631401B2 (en) * 2007-07-24 2014-01-14 Ca, Inc. Capacity planning by transaction type
US8458670B2 (en) * 2007-09-27 2013-06-04 Symantec Corporation Automatically adding bytecode to a software application to determine network communication information
US9021505B2 (en) * 2007-12-07 2015-04-28 Ca, Inc. Monitoring multi-platform transactions
US8261278B2 (en) * 2008-02-01 2012-09-04 Ca, Inc. Automatic baselining of resource consumption for transactions
US8402468B2 (en) * 2008-03-17 2013-03-19 Ca, Inc. Capacity planning based on resource utilization as a function of workload
US7797415B2 (en) * 2008-04-29 2010-09-14 Computer Associates Think, Inc. Automatic context-based baselining for transactions
CN104407518B (en) 2008-06-20 2017-05-31 因文西斯系统公司 The system and method interacted to the reality and Simulation Facility for process control
US8327377B2 (en) * 2009-04-30 2012-12-04 Ca, Inc. Detecting, logging and tracking component dependencies in web service transactions
US8423973B2 (en) * 2009-05-08 2013-04-16 Ca, Inc. Instrumenting an application with flexible tracers to provide correlation data and metrics
US8127060B2 (en) 2009-05-29 2012-02-28 Invensys Systems, Inc Methods and apparatus for control configuration with control objects that are fieldbus protocol-aware
US8463964B2 (en) 2009-05-29 2013-06-11 Invensys Systems, Inc. Methods and apparatus for control configuration with enhanced change-tracking
US20100333079A1 (en) * 2009-06-30 2010-12-30 Computer Associates Think, Inc. Binary Code Modification System and Method for Implementing Identity and Access Management or Governance Policies
US20100333065A1 (en) * 2009-06-30 2010-12-30 Computer Assoicates Think, Inc. Binary code modification system and method for implementing a web service interface
US20110098973A1 (en) * 2009-10-23 2011-04-28 Computer Associates Think, Inc. Automatic Baselining Of Metrics For Application Performance Management
US8977664B2 (en) 2010-02-17 2015-03-10 Ca, Inc. System for storing and transmitting compressed integer data
US9569326B2 (en) 2010-04-15 2017-02-14 Ca, Inc. Rule organization for efficient transaction pattern matching
US8490055B2 (en) 2010-09-17 2013-07-16 Ca, Inc. Generating dependency maps from dependency data
US8938729B2 (en) 2010-10-12 2015-01-20 Ca, Inc. Two pass automated application instrumentation
US8578487B2 (en) 2010-11-04 2013-11-05 Cylance Inc. System and method for internet security
US20120151450A1 (en) * 2010-12-09 2012-06-14 Microsoft Corporation Platform-Agnostic Diagnostic Data Collection and Display
US8438427B2 (en) 2011-04-08 2013-05-07 Ca, Inc. Visualizing relationships between a transaction trace graph and a map of logical subsystems
US8516301B2 (en) * 2011-04-08 2013-08-20 Ca, Inc. Visualizing transaction traces as flows through a map of logical subsystems
US9202185B2 (en) 2011-04-08 2015-12-01 Ca, Inc. Transaction model with structural and behavioral description of complex transactions
US8782614B2 (en) 2011-04-08 2014-07-15 Ca, Inc. Visualization of JVM and cross-JVM call stacks
US9116717B2 (en) 2011-05-27 2015-08-25 Cylance Inc. Run-time interception of software methods
US9817656B2 (en) 2012-08-24 2017-11-14 Ca, Inc. Hot rollback of updated agent
US9798557B2 (en) 2012-08-24 2017-10-24 Ca, Inc. Injection of updated classes for a java agent
US9507609B2 (en) * 2013-09-29 2016-11-29 Taplytics Inc. System and method for developing an application
WO2016048294A1 (en) * 2014-09-24 2016-03-31 Hewlett Packard Enterprise Development Lp Infrastructure rule generation

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5193180A (en) 1991-06-21 1993-03-09 Pure Software Inc. System for modifying relocatable object code files to monitor accesses to dynamically allocated memory
US6021272A (en) 1995-10-04 2000-02-01 Platinum Technology, Inc. Transforming and manipulating program object code

Cited By (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7024657B2 (en) * 2000-02-21 2006-04-04 Matsushita Electric Industrial Co., Ltd. Program generation apparatus for program execution system, replaces variable name in each class file by assigned offset number so that same offset numbers are assigned to non-dependent variables with same variable name
US20040205710A1 (en) * 2000-02-21 2004-10-14 Masaki Kawai Program generation apparatus
WO2004097603A1 (en) * 2003-05-02 2004-11-11 Bitarts Limited Protecting a java application
US20050209863A1 (en) * 2004-03-05 2005-09-22 International Business Machines Corporation Reducing the run-time cost of invoking a server page
US7458070B2 (en) 2004-03-05 2008-11-25 International Business Machines Corporation Reducing the run-time cost of invoking a server page
US20090055811A1 (en) * 2004-03-05 2009-02-26 International Business Machines Corporation Reducing the run-time cost ofinvoking a server page
US8214815B2 (en) * 2004-03-05 2012-07-03 International Business Machines Corporation Reducing the run-time cost of invoking a server page
US8353009B2 (en) * 2009-10-01 2013-01-08 Nokia Corporation Method and apparatus for providing context access with property and interface obfuscation
US20110083162A1 (en) * 2009-10-01 2011-04-07 Nokia Corporation Method and apparatus for providing context access with property and interface obfuscation
US8478705B2 (en) 2010-01-15 2013-07-02 International Business Machines Corporation Portable data management using rule definitions
US20110178971A1 (en) * 2010-01-15 2011-07-21 International Business Machines Corporation Portable data management
US9256827B2 (en) 2010-01-15 2016-02-09 International Business Machines Corporation Portable data management using rule definitions
US8666998B2 (en) 2010-09-14 2014-03-04 International Business Machines Corporation Handling data sets
US8949166B2 (en) 2010-12-16 2015-02-03 International Business Machines Corporation Creating and processing a data rule for data quality
US8898104B2 (en) 2011-07-26 2014-11-25 International Business Machines Corporation Auto-mapping between source and target models using statistical and ontology techniques
US20160323396A1 (en) * 2015-04-30 2016-11-03 AppDynamics, Inc. Agent Asynchronous Transaction Monitor
US9838488B2 (en) * 2015-04-30 2017-12-05 Appdynamics Llc Agent asynchronous transaction monitor
US10165074B2 (en) * 2015-04-30 2018-12-25 Cisco Technology, Inc. Asynchronous custom exit points
US11263110B1 (en) * 2015-12-31 2022-03-01 EMC IP Holding Company LLC Inter-object validation system and method for the objects of a test system
CN106843912A (en) * 2017-03-22 2017-06-13 武汉斗鱼网络科技有限公司 Page info acquisition methods and device

Also Published As

Publication number Publication date
US6260187B1 (en) 2001-07-10

Similar Documents

Publication Publication Date Title
US6260187B1 (en) System for modifying object oriented code
Keller et al. Binary component adaptation
US7552433B2 (en) Non-platform-specific unique indentifier generation
US7225438B2 (en) Lazy compilation of template-generated classes in dynamic compilation execution environments
US11366643B2 (en) Generating dynamic modular proxies
CN107924326B (en) Overriding migration methods of updated types
US6901586B1 (en) Safe language static variables initialization in a multitasking system
US11693719B2 (en) Implementing a type restriction that restricts to a non-polymorphic layout type or a maximum value
US10853110B2 (en) Constructor accessibility checks for deserialization
US11347487B2 (en) Confining reflective access based on module boundaries
Bertelsen Dynamic semantics of Java bytecode
Meijer et al. Overcoming independent extensibility challenges
US11568047B2 (en) Distinguished nest-based access control
US11243876B2 (en) Techniques for accessing off-heap memory
US11803487B2 (en) Transitioning between thread-confined memory segment views and shared memory segment views
Villela et al. . NET Platform
Jadhav CORE JAVA UNIT 1-SEM IV
US20040221266A1 (en) Non-forgeable objects in an object system
Steeb et al. Programming in CSharp

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION