A Java bytecode modification method and device

Abstract

The present invention proposes a Java bytecode modification method and device, which not only reduces the complexity of building a compilation environment, but also does not require developers to understand the details of the bytecode protocol. Its input is two bytecode files: the bytecode file to be modified and the target bytecode file. The tool will parse and compare the two bytecode files, then incrementally merge the differences of the target bytecode file into the bytecode file to be modified, and finally output the modified bytecode file.

Description

[Technical field]

[0001] The present invention relates to the field of bytecode modification, and in particular to a Java bytecode modification method and device. [Background technology]

[0002] Java developers need to modify the bytecode during daily development and maintenance. There are currently two mainstream ways to modify the bytecode.

[0003] The first method is to modify the original complete source code file corresponding to the bytecode file, compile it to generate a bytecode file, and then replace it. This method requires developers to obtain the original complete source code file and all the library files it depends on, and then build a compilation environment for compilation.

[0004] The second method is to use some bytecode modification tools to modify the bytecode file directly. As Java is an open source language, the protocol of its bytecode file is also public and can be found on the official website. Therefore, you can write a tool to refer to the protocol and directly modify the data of the bytecode file. Common tools of this type currently include ASM, BCEL, and Javassist. This method is relatively simple to build a compilation environment. It only requires Java developers to create a Java project, use the tool's API to load the bytecode file in the project, modify it, and then save and export it.

[0005] The first method is currently the most commonly used method. The disadvantage is that if the source code file corresponding to the bytecode is relatively large, it will be cumbersome to build the compilation environment, and all its dependent files need to be referenced before compilation. In addition, the source code file corresponding to the bytecode is sometimes not available, and developers need to use decompilation tools to decompile from the bytecode file. The decompiled source file often has compilation problems when recompiled, and needs to be repaired based on experience. The larger the file, the greater the probability of compilation problems. The second method is very simple to build a compilation environment, but the disadvantage is that it requires developers to be very familiar with the bytecode protocol and tool API, which is a relatively high requirement.

[0006] Therefore, a new bytecode modification method is needed that can combine the advantages of the above two methods, reduce the complexity of building a compilation environment, and do not require developers to understand the details of the bytecode protocol, thereby improving the efficiency of modifying bytecode. [Summary of the invention]

[0007] In view of the above defects or improvement needs, in order to reduce the complexity of building a compilation environment and improve the efficiency of developers' maintenance and modification, the present invention provides a new bytecode modification method, which not only reduces the complexity of building a compilation environment, but also does not require developers to understand the details of the bytecode protocol. Its input is two bytecode files: the bytecode file to be modified and the target bytecode file. The tool will parse and compare the two bytecode files, and then incrementally merge the differences of the target bytecode file into the bytecode file to be modified, and finally output the modified bytecode file.

[0008] To achieve the above object, the present invention adopts the following technical solution:

[0009] In the first aspect, a Java bytecode modification method is as follows:

[0010] Parse the bytecode file to be modified and the target bytecode file into the data object ClassFile to be modified and the target data object ClassFile respectively according to the bytecode protocol, add the constant pool in the target data object ClassFile to the data object ClassFile to be modified, add the newly added member objects in the target data object ClassFile to the data object ClassFile to be modified in sequence, add the newly added methods in the target data object ClassFile to the data object ClassFile to be modified in sequence, export the modified data object ClassFile to be modified and save it as a bytecode file according to the bytecode protocol.

[0011] Preferably, the constant pool of the target data object ClassFile is traversed, and the constant pool is added to the data object ClassFile to be modified in batches.

[0012] Preferably, there is a reference relationship between the constant pools in the target data object ClassFile, and the referenced constant pool needs to be first added from the target data object ClassFile to the data object ClassFile to be modified, and the position of the referenced constant pool in the data object ClassFile to be modified is obtained, and the reference position of the referenced constant pool in the target data object ClassFile is updated, and then the updated referenced constant pool is added from the target data object ClassFile to the data object ClassFile to be modified.

[0013] Preferably, the member variables in the target data object ClassFile are traversed, and the member variables in the target data object ClassFile are compared with the member variables in the data object ClassFile to be modified. If the member variables to be added do not exist in the data object ClassFile to be modified, the member variables are directly added to the data object ClassFile to be modified; if the member variables to be added are the same as the member variables in the data object ClassFile to be modified, the member variables to be added are overwritten in the data object ClassFile to be modified.

[0014] Preferably, the member variables of the target data object ClassFile and the member variables of the data object ClassFile to be modified are traversed and compared one by one, and the comparison is based on whether the values ​​of the constant pool corresponding to the name_index of the member variable field_info are the same.

[0015] Preferably, the methods in the target data object ClassFile are traversed, and the methods in the target data object ClassFile are compared with the methods in the data object ClassFile to be modified. If the method to be added does not exist in the data object ClassFile to be modified, and the method name starts with "wclassfile", the method is added to the data object ClassFile to be modified; if the method name does not start with "wclassfile", the method is not added; if the method to be added is the same as the method in the data object ClassFile to be modified, the method to be added is overwritten in the data object ClassFile to be modified.

[0016] Preferably, after the newly added member variables and newly added methods in the target data object ClassFile are added to the data object ClassFile to be modified, the reference index to the constant pool in the internal attributes of the member variables and the reference index to the constant pool in the internal attributes of the methods are modified.

[0017] Preferably, after the newly added method in the target data object ClassFile is added to the data object ClassFile to be modified, the reference index to the constant pool in the internal attributes of the method is modified.

[0018] Preferably, the modified data object ClassFile to be modified is exported and saved as a bytecode file according to the bytecode protocol.

[0019] In a second aspect, a Java bytecode modification device comprises at least one processor and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the processor for the Java bytecode modification method.

[0020] The present invention provides a Java bytecode modification method, which not only reduces the complexity of building a compilation environment, but also does not require developers to understand the details of the bytecode protocol, thereby greatly improving the speed and efficiency of developers in modifying development.

Brief Description of the Drawings

[0021] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the embodiments of the present invention. Obviously, the drawings described below are only some embodiments of the present invention, and for ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0022] Figure 1 It is a schematic diagram of an implementation flow of a Java bytecode modification method provided by an embodiment of the present invention;

[0023] Figure 2 It is a flowchart of a Java bytecode modification method provided by an embodiment of the present invention;

[0024] Figure 3 It is a schematic diagram of a constant pool merging process of a Java bytecode modification method provided by an embodiment of the present invention;

[0025] Figure 4 It is a schematic diagram of a member variable merging process of a Java bytecode modification method provided by an embodiment of the present invention;

[0026] Figure 5 It is a schematic diagram of a merging method flow of a Java bytecode modification method provided by an embodiment of the present invention;

[0027] Figure 6 It is a schematic diagram of a Java bytecode modification device provided by an embodiment of the present invention. [Specific implementation method]

[0028] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention. In addition, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0029] Embodiment 1:

[0030] The embodiment of the present invention provides a Java bytecode modification method, such as Figure 1 shown.

[0031] In this embodiment, the bytecode modification reads the bytecode file A1 to be modified and the target bytecode file C1, and parses them into the data object ClassFile A2 to be modified and the target data object ClassFile C2 respectively according to the bytecode protocol. In this embodiment, the data object ClassFile A2 to be modified is referred to as A2, and the target data object ClassFile C2 is referred to as C2.

[0032] like Figure 2 As shown, a Java bytecode modification method is as follows:

[0033] Step 201 , parse the bytecode file A1 to be modified and the target bytecode file C1 into the data object ClassFileA2 to be modified and the target data object ClassFileC2 respectively according to the bytecode protocol.

[0034] Among them, the data structure of the data object ClassFile in the present invention mainly involves the following attribute types:

[0035] cp_info, field_info and method_info; cp_info in this embodiment becomes a constant pool, field_info in this embodiment is called a member variable, and method_info in this embodiment is called a method.

[0036] Step 202: Add the constant pool in the target data object ClassFileC2 to the data object ClassFileA2 to be modified.

[0037] Step 203: Add the newly added member objects in the target data object ClassFileC2 to the data object to be modified ClassFileA2 in sequence.

[0038] Step 204: Add the newly added methods in the target data object ClassFileC2 to the data object to be modified ClassFileA2 in sequence.

[0039] Step 205, export the modified data object ClassFileA2 to be modified and save it as a bytecode file according to the bytecode protocol.

[0040] Among them, the ClassFile data structure is as follows:

[0041]

[0042]

[0043] The constant pool attribute type is cp_info, and the attribute name is constant_pool; wherein, the cp_info data structure is as follows:

[0044]

[0045] The constant pool stores all constants of the data object ClassFile, including strings and values. The strings represent class names, variable names, method names, etc. in the source file. The constant pool is used to be referenced by other attributes through indexes. The constant pool is an array with multiple members, which can also reference each other. There are many different types of constant pools, which are distinguished by tags.

[0046] The member variable attribute type is field_info, the attribute name is fields, and each member variable has attributes such as name and access level (private / protected / public); wherein the field_info data structure is as follows:

[0047]

[0048] The method attribute type is method_info, the attribute name is methods, and each method has attributes such as name and access level (private / protected / public). The method_info data structure is as follows:

[0049]

[0050] like Figure 3 As shown, the Java bytecode modification method involves the following designs in merging constant pools:

[0051] Step 301, traverse the constant pool of C2 in three batches.

[0052] Step 302: Add the constant pool to A2 in batches.

[0053] Since there is a reference relationship between constant pools, they need to be added to A2 in batches. The referenced ones need to be added first to obtain their new positions in A2. The referencers need to update the reference positions and then add them to A2.

[0054] Step 303, check whether the constant object is referenced, if the constant object is referenced, jump to 304, if the constant object is not referenced, jump to 305.

[0055] Step 304, obtain its new position in A2, the referencer needs to update the reference position, and jump to step 302.

[0056] Since the position of each constant pool may change after it is added from C2 to A2, the constant pool referer needs to update the reference index; all constant pools added from C2 to A2 need to save the new position of the constant pool for use in subsequent steps.

[0057] Step 305, check whether the traversal is finished, if so, then end directly, otherwise jump to 301.

[0058] Among them, the constant pool types are as follows, as shown in Table 1:

[0059]

[0060]

[0061] Table 1

[0062] The three batches of constant pools are as follows:

[0063] The first batch is shown in Table 2:

[0064] tag meaning 1 CONSTANT_Utf8 3 CONSTANT_Integer 4 CONSTANT_Float 5 CONSTANT_Long 6 CONSTANT_Double

[0065] Table 2

[0066] The second batch is shown in Table 3:

[0067] tag meaning 7 CONSTANT_Class (references CONSTANT_Utf8) 8 CONSTANT_String (reference CONSTANT_Utf8) 12 CONSTANT_NameAndType (reference CONSTANT_Utf8)

[0068] Table 3

[0069] The third batch is shown in Table 4:

[0070] tag meaning 9 CONSTANT_Fieldref (reference CONSTANT_String) 10 CONSTANT_Methodref (reference CONSTANT_String) 11 CONSTANT_InterfaceMethodref (reference CONSTANT_String) 15 CONSTANT_MethodHandle (reference CONSTANT_String) 16 CONSTANT_MethodType (reference CONSTANT_String) 18 CONSTANT_InvokeDynamic (reference CONSTANT_String)

[0071] Table 4

[0072] like Figure 4 As shown, the Java bytecode modification method involves the following design in merging member variables:

[0073] Step 401, traverse the member variables in C2.

[0074] Step 402, compare the member variables in C2 with the member variables in A2, and the comparison basis is whether the value of the constant pool corresponding to the name_index of the member variable field_info is the same. If the member variables in C2 are compared with the member variables in A2, and the member variables in C2 exist in A2, jump to 403; if the member variables in C2 do not exist in A2, jump to 404.

[0075] Step 403: If the member variables in C2 are identical to the member variables in A2, the member variables in C2 are used to overwrite the identical member variables in A2.

[0076] Step 404: If the member variables in C2 do not exist in A2, then the member variables in C2 are added to A2.

[0077] Step 405: After the newly added member object in C2 is added to A2, it is necessary to update the location of the corresponding constant pool and modify the values ​​referenced by all constant pools of the newly added member variables to ensure the correctness of A2.

[0078] Step 406, check whether the traversal is finished, if so, then end, otherwise jump to 401.

[0079] like Figure 5 As shown, the Java bytecode modification method involves the following designs in the merging method:

[0080] Step 501, traverse the methods in C2.

[0081] Step 502, compare the method in C2 with the method in A2, the comparison basis is whether the value of the constant pool corresponding to the name_index of the method_info is the same, if the method exists in A2, jump to 503, if the method does not exist in A2, jump to 504.

[0082] Step 503: If the method to be added has the same method in A2, the method to be added is overwritten in A2.

[0083] Step 504, if the method to be added does not exist in A2, and the method starts with "wclassfile", jump to 505; if the method does not start with "wclassfile", the method is not added and jump to 508; whether the method is needed is determined by whether the method starts with "wclassfile".

[0084] Step 506, after the method in C2 is placed in A2, it is necessary to update the location of the corresponding constant pool and modify the values ​​referenced by all constant pools of the newly added method, such as name_index and descriptor_index, to ensure the correctness of A2.

[0085] Step 507: Update the Code instruction in the method attributes.

[0086] Step 508, check whether the traversal is finished, if so, then end directly, otherwise jump to 501.

[0087] Among them, method_info also includes attribute. In attribute_info, the type of the attribute_info is determined according to the value of the constant pool corresponding to attribute_name_index. There are three types of attribute_info that need to be updated:

[0088] The data structure corresponding to Code is as follows:

[0089]

[0090] Among them, attribute_name_index, code[code_length], start_pc, end_pc, handler_pc, exception_table and attribute_info attributes[attributes_count] need to be checked and modified after the method is added.

[0091] The attribute_name_index needs to be modified to the new constant pool location. The code attribute is a series of sequences after parsing. Since some instructions will reference the location of the constant pool, the modification of the constant pool location will also lead to the modification of the instructions. The modification of the instructions will lead to the modification of all the contents in exception_table_length. Therefore, the above data structure needs to be modified.

[0092] The data structure corresponding to Signatrue info is as follows:

[0093]

[0094]

[0095] Among them, attribute_name_index and signature_index need to be modified to the new constant pool index.

[0096] The data structure corresponding to Exceptions is as follows:

[0097]

[0098] Among them, attribute_name_index and exception_index_table need to be modified to the new constant pool index.

[0099] After the constant pool merging, member variable merging and method merging are all completed, the modified bytecode file D is exported, and the data object ClassFileA2 to be modified is saved as a bytecode file.

[0100] The Java bytecode modification method is released in the form of a jar package, and the release form is: WClassfile.jar, where WClassfile is the name of the jar package. The name can be changed according to the needs of technical personnel in this field during specific use, and should not limit the protection scope of the present invention.

[0101] It can be called through commands. The usage is:

[0102] Java-jarWClassfile.jar-o= / filepath-n= / filepath-s= / dirpath

[0103] The specific parameters are:

[0104] -o: bytecode file path to be modified

[0105] -n: target bytecode file path

[0106] -s: The modified bytecode file save directory

[0107] Embodiment 2:

[0108] The embodiment of the present invention proposes a Java bytecode modification method. Based on the embodiment 1, this embodiment further uses a specific example to illustrate the specific implementation mode of the present invention.

[0109] In this embodiment, there is a bytecode file Sample.class to be modified. The source code file and the compilation environment of the bytecode file Sample.class to be modified are no longer available. It is necessary to add debugging information to a method method_d inside the bytecode file and record the value of the input parameter i in the log file.

[0110] Decompile Sample.class using the decompilation tool and obtain its source code fragment as follows:

[0111]

[0112] This code snippet only includes 4 methods. Refer to the code snippet above. Since the goal is to modify mehtod_d, the focus of the target source file is to ensure the integrity of this method and ensure successful compilation. The code snippet after modifying mehtod_d is as follows:

[0113]

[0114] Comparing this with the decompiled source code snippet of Sample.class, we can see the following differences:

[0115] 1. mehtod_d adds a line "Logger.getLogger(getClass()).info("method_c,i="+i);" to meet our modification requirements and add debugging information.

[0116] 2. The implementation of method_a and method_b is empty; this is because these two methods are not our modification targets, so they can be left unimplemented; but since method_d is calling it, the code can be compiled successfully.

[0117] 3. The private access level of method_a and method_b is inconsistent with the public access level of the code snippet. This is to prevent these two incomplete methods from overwriting the method of the bytecode file to be modified.

[0118] Among them, although the two methods method_a and method_b do not exist in the bytecode file to be modified, their names do not start with "wclassfile_", so they will not be added to the modified bytecode file.

[0119] 4. The target source file does not contain method_c. This is because the method method_c is not associated with method_d, and its absence does not affect the integrity of method_d.

[0120] Use the JDK compilation instruction Javac to compile the target source file (Sample.java) to generate the target bytecode file (Sample.class). The specific operations are as follows:

[0121] Open a command line in path C: and run:

[0122] Javac C: / new / Sample.Java

[0123] Generate the modified bytecode file; save the bytecode file to be modified to C: / old, and save the target bytecode file to C: / new. Open the command line in path C: and run:

[0124] Java-jar WClassfile.jar-o=C: / old / Sample.class-n=C: / new / Sample.class-s=C: /

[0125] After the program runs successfully, a new Sample.class will be generated in the directory "C: / ". The code snippet is as follows when viewed through the decompilation tool:

[0126]

[0127]

[0128] Among them, mehtod_d added a line "Logger.getLogger(getClass()).info("method_c,i="+i);" to meet our modification requirements. It can be seen that this modification is successful.

[0129] Embodiment 3:

[0130] The embodiment of the present invention proposes a Java bytecode modification method. In practical applications, it can be used in combination with different technical tools according to different application scenarios. Based on Example 1, this embodiment provides a specific implementation plan in the scenario of using JavaAgent technology together.

[0131] Used in conjunction with JavaAgent technology, modifications to third-party libraries or JRE are deployed separately from Java applications, and loaded on demand when the Java application is started, preventing changes to third-party libraries or JRE from affecting other Java applications in the deployment environment.

[0132] The specific process is as follows:

[0133] JRE (Java Runtime Environment) and two Java applications are deployed on the server, located in the C: / ProgramA and C: / ProgramB directories respectively. ProgramA may fail during operation. To troubleshoot this failure, the developer needs to modify the String class that comes with JDK and add some specific codes to its constructor. In order not to affect ProgramB, it is required not to modify it directly on JRE.

[0134] The implementation process refers to the above-mentioned Example 2, and the target source file is as follows:

[0135]

[0136] Among them, if(original.equals("abc")){throw RuntimeException("got it");} in the above target source file is the new part of the target source file compared with the String source code.

[0137] Referring to Example 2, a target bytecode file String.class is generated and placed in the C: / ProgramA directory. Then, a JavaAgent is written based on the method of the present invention and named TestAgent. The code is as follows:

[0138]

[0139]

[0140] From the above code, it can be seen that TestAgent calls the method provided by the present invention to perform bytecode modification.

[0141] The release format of this Java bytecode modification method is: WClassfile.jar.

[0142] Start ProgramA and run:

[0143] Java-Javaagent:TestAgent.jar-jar C: / ProgamA.jar

[0144] The JavaAgent technology is used to call the above TestAgent.jar, and finally TestAgent calls the method provided by the present invention to complete the bytecode modification.

[0145] Embodiment 4:

[0146] like Figure 6 , which is a schematic diagram of the architecture of a Java bytecode modification device according to an embodiment of the present invention. The Java bytecode modification method recommendation device according to this embodiment includes one or more processors 601 and a memory 602. Figure 6 A processor 601 is taken as an example.

[0147] The processor 601 and the memory 602 may be connected via a bus or other means. Figure 6 The example of connecting through bus is taken in the following.

[0148] The memory 602 is a non-volatile computer-readable storage medium that can be used to store non-volatile software programs and non-volatile computer executable programs, such as the Java bytecode modification method in Example 1. The processor 601 executes the Java bytecode modification method by running the non-volatile software programs and instructions stored in the memory 602.

[0149] The memory 602 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage devices. In some embodiments, the memory 602 may optionally include a memory remotely arranged relative to the processor 601, and these remote memories may be connected to the processor 601 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0150] The program instructions / modules are stored in the memory 602, and when executed by the one or more processors 601, the Java bytecode modification method in the above embodiment 1 is executed, for example, the Java bytecode modification method described above is executed. Figures 2 to 5 The steps shown.

[0151] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the protection scope of the present invention.

Claims

1. A Java bytecode modification method, characterized in that: Parse the bytecode file to be modified and the target bytecode file into the data object ClassFile to be modified and the target data object ClassFile respectively according to the bytecode protocol, add the constant pool in the target data object ClassFile to the data object ClassFile to be modified, add the newly added member objects in the target data object ClassFile to the data object ClassFile to be modified in sequence, add the newly added methods in the target data object ClassFile to the data object ClassFile to be modified in sequence, export the modified data object ClassFile to be modified and save it as a bytecode file according to the bytecode protocol; The newly added methods in the target data object ClassFile are added to the data object ClassFile to be modified in sequence, characterized in that the methods in the target data object ClassFile are traversed, and the methods in the target data object ClassFile are compared with the methods in the data object ClassFile to be modified. If the method to be added does not exist in the data object ClassFile to be modified, and the method name starts with "wclassfile", the method is added to the data object ClassFile to be modified; if the method name does not start with "wclassfile", the method is not added; if the method to be added is the same as the method in the data object ClassFile to be modified, the method to be added is overwritten in the data object ClassFile to be modified.

2. A Java bytecode modification method according to claim 1, characterized in that: The constant pool in the target data object ClassFile is added to the data object ClassFile to be modified in batches, characterized in that the constant pool of the target data object ClassFile is traversed and the constant pool is added to the data object ClassFile to be modified in batches.

3. A Java bytecode modification method according to claim 2, characterized in that: There is a reference relationship between the constant pools in the target data object ClassFile. The referenced constant pool needs to be added from the target data object ClassFile to the data object ClassFile to be modified first, and the position of the referenced constant pool in the data object ClassFile to be modified is obtained, and the reference position of the referenced constant pool in the target data object ClassFile is updated, and then the updated referenced constant pool is added from the target data object ClassFile to the data object ClassFile to be modified.

4. A Java bytecode modification method according to claim 1, characterized in that: The newly added member objects in the target data object ClassFile are added to the data object ClassFile to be modified in sequence, characterized in that the member variables in the target data object ClassFile are traversed, and the member variables in the target data object ClassFile are compared with the member variables in the data object ClassFile to be modified. If the member variables to be added do not exist in the data object ClassFile to be modified, the member variables are directly added to the data object ClassFile to be modified; if the member variables to be added are the same as the member variables in the data object ClassFile to be modified, the member variables to be added are overwritten in the data object ClassFile to be modified.

5. A Java bytecode modification method according to claim 4, characterized in that: The member variables of the target data object ClassFile and the member variables of the data object ClassFile to be modified are traversed and compared one by one. The comparison is based on whether the values ​​of the constant pool corresponding to the name_index of the member variable field_info are the same.

6. A Java bytecode modification method according to claim 1, characterized in that: The methods of the target data object ClassFile and the methods of the data object ClassFile to be modified are traversed and compared one by one. The comparison is based on whether the values ​​of the constant pool corresponding to the name_index of the method_info are the same.

7. A Java bytecode modification method according to any one of claims 4 to 6, characterized in that: After the newly added member variables and newly added methods in the target data object ClassFile are added to the data object ClassFile to be modified, the reference index to the constant pool in the internal attributes of the member variables and the reference index to the constant pool in the internal attributes of the methods are modified.

8. A Java bytecode modification method according to claim 1, characterized in that: Export the modified data object ClassFile to be modified and save it as a bytecode file according to the bytecode protocol.

9. A Java bytecode modification device, characterized in that: The Java bytecode modification device includes at least one processor and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the processor to execute the Java bytecode modification method described in any one of claims 1-8.

Images