Java migration compatibility processing method, device and storage medium

Abstract

The embodiment of the present invention discloses a Java migration compatibility processing method, device and storage medium, the method comprising: decompiling the application to be migrated to obtain the involved classes, methods and interfaces; analyzing the current JDK of the application and the JDK after migration to generate a difference database, wherein a plurality of minimum difference units are recorded in the difference database; determining the involved minimum difference unit according to the involved classes, methods and interfaces and the difference database; searching for the corresponding modification strategy according to the involved minimum difference unit using a preset compatibility modification strategy file; searching for the location of the involved minimum difference unit using the modification strategy, and replacing the bytecode at the location using the modification strategy. Compared with the existing method, the modification workload can be effectively reduced, and the compatibility processing can be completed quickly and accurately, which is particularly suitable for maintaining large and complex applications.

Description

Technical Field

[0001] The present invention relates to the technical field of Java migration, and in particular to a Java migration compatibility processing method, device and storage medium. Background Art

[0002] With the rapid development of computer technology and the rise of the domestic substitution trend, more and more companies are replacing their business environments with domestic ones. Java has been widely used in big data, cloud computing, financial services, e-commerce and other fields. With the end of the maintenance cycle of the JDK version used by enterprises and the need for higher performance business development, it is necessary to replace or upgrade the JDK version.

[0003] Java applications usually rely on the standard libraries and APIs provided by the Java Development Kit (JDK). When the JDK version is updated, the API may change, such as the addition, deletion, and modification of methods. These changes may cause Java applications to be incompatible between different JDK versions, affecting the normal use of Java applications. Summary of the invention

[0004] The embodiments of the present invention provide a Java migration compatibility processing method, device and storage medium to solve the technical problem in the prior art that Java applications are incompatible between different JDK versions, which affects the normal use of Java applications.

[0005] In a first aspect, an embodiment of the present invention provides a Java migration compatibility processing method, comprising:

[0006] Decompile the application to be migrated to obtain the classes, methods, and interfaces involved;

[0007] Analyze the current JDK and the migrated JDK of the application to generate a difference database, wherein the difference database records a plurality of minimum difference units;

[0008] Determine the minimum difference unit involved according to the classes, methods and interfaces involved and the difference database;

[0009] Using a preset compatibility modification strategy file, searching for a corresponding modification strategy according to the minimum difference unit involved;

[0010] The modification strategy is used to find the location of the involved minimum difference unit, and the bytecode at the location is replaced using the modification strategy.

[0011] In a second aspect, an embodiment of the present invention further provides a Java migration compatibility processing device, comprising:

[0012] The acquisition module is used to decompile the application to be migrated and obtain the classes, methods, and interfaces involved;

[0013] A generation module, used for analyzing the current JDK and the migrated JDK of the application to generate a difference database, wherein the difference database records a plurality of minimum difference units;

[0014] A determination module, used for determining the minimum difference unit involved according to the classes, methods and interfaces involved and the difference database;

[0015] A search module, used for searching a corresponding modification strategy according to the minimum difference unit involved by using a preset compatibility modification strategy file;

[0016] A replacement module is used to use the modification strategy to find the location of the minimum difference unit involved, and replace the bytecode at the location using the modification strategy.

[0017] In a third aspect, an embodiment of the present invention further provides a storage medium comprising computer executable instructions, wherein the computer executable instructions, when executed by a computer processor, are used to execute the Java migration compatibility processing method provided in the above embodiment.

[0018] The Java migration compatibility processing method, device and storage medium provided by the embodiment of the present invention decompile the application to be migrated to obtain the involved classes, methods and interfaces; analyze the current JDK of the application and the JDK after migration to generate a difference database, in which multiple minimum difference units are recorded; determine the involved minimum difference unit according to the involved classes, methods and interfaces and the difference database; use a preset compatibility modification strategy file to find the corresponding modification strategy according to the involved minimum difference unit; use the modification strategy to find the location of the involved minimum difference unit, and use the modification strategy to replace the bytecode at the location. By analyzing the application to be migrated, the current JDK and the JDK to be migrated, multiple minimum difference units are obtained, and the incompatible factors and corresponding bytecode modification strategies are determined according to the minimum difference units to modify the bytecode. It can effectively deal with compatibility issues caused by version upgrades without modifying the source code or recompiling. Compared with the existing methods, it can effectively reduce the modification workload, quickly and accurately complete the compatibility processing, and is particularly suitable for maintaining large and complex applications. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Other features, objects and advantages of the present invention will become more apparent from the detailed description of non-limiting embodiments made with reference to the following drawings:

[0020] Figure 1It is a flowchart of a Java migration compatibility processing method provided in the first embodiment of the present invention;

[0021] Figure 2 It is a flowchart of a Java migration compatibility processing method provided in Embodiment 2 of the present invention;

[0022] Figure 3 It is a structural diagram of a Java migration compatibility processing device provided in Embodiment 3 of the present invention. DETAILED DESCRIPTION

[0023] The present invention will be further described in detail below in conjunction with the accompanying drawings and embodiments. It is to be understood that the specific embodiments described herein are only used to explain the present invention, rather than to limit the present invention. It should also be noted that, for ease of description, only parts related to the present invention, rather than all structures, are shown in the accompanying drawings.

[0024] Embodiment 1

[0025] Figure 1 : is a flowchart of a Java migration compatibility processing method provided in Embodiment 1 of the present invention. This embodiment is applicable to the case where an application using an old version of an API encounters compatibility issues in a new JDK environment. The method can be executed by a Java migration compatibility processing device and specifically includes the following steps:

[0026] Step 110, decompile the application to be migrated to obtain the classes, methods and interfaces involved.

[0027] For example, after inputting the path of the Java application and its dependent jar packages, temporary data for bytecode analysis can be generated to implement decompilation processing. And according to the result of the decompilation processing, the involved classes, methods and interfaces can be obtained. The involved classes, methods and interfaces can be the classes, methods and interfaces used in the application to be migrated.

[0028] Step 120: Analyze the current JDK and the migrated JDK of the application to generate a difference database, wherein the difference database records a plurality of minimum difference units.

[0029] JDK is a Java language toolkit that provides tools such as a virtual machine, compiler, and debugger for executing Java. Because there are differences in JDK interfaces, applications need to modify source code for adaptation. Therefore, it is necessary to analyze the current JDK and the migrated JDK to determine the differences between the two.

[0030] Exemplarily, it may include: parsing the standard library files in different versions of JDK, extracting all class, method and field information, and saving the information to the API database; using the bytecode analysis engine to perform bytecode analysis on the current JDK and the migrated JDK of the application to obtain analysis results; performing compatibility analysis of java classes, methods and interfaces respectively according to the analysis results; generating a data file for saving incompatible java classes, methods and interfaces according to the compatibility analysis results. Exemplarily, the analysis results may be differences at the class, method and field levels. These differences include the addition, deletion, modification of methods, and changes in access modifiers, etc.

[0031] Furthermore, the bytecode analysis engine may be used to perform bytecode analysis on the current JDK and the migrated JDK of the application to obtain analysis results in the following manner:

[0032] Use the newly added JarBytecodeAnalyzer class to scan the class bytecode in the Java application jar package;

[0033] Use the newly added JClassVisitor class to inherit org.objectweb.asm.Visitor to process the bytecode of each class;

[0034] Use the newly added JMethodVisitor class to inherit org.objectweb.asm.MethodVisitor to process each method in the class bytecode;

[0035] The parsed results can be stored in the MethodInvocation entity class to record the class name, method fully qualified name, method descriptor, whether it is an interface tag, and class compatibility status, thus forming a difference database.

[0036] Exemplarily, the minimum difference unit may be directly modifiable without affecting the modification of other minimum difference units. Exemplarily, the minimum difference unit may include: class_name: class name; class_methods: array of methods; method_name: method name; method_descriptor: method descriptor (such as parameters and return type); jdk_invocations: array of calls to JDK methods; jdk_class_name: JDK class name; jdk_method_name: JDK method name; jdk_method_descriptor: JDK method descriptor; InterfaceObject: a newly added part used to describe the compatibility information of the interface; interface_name: interface name; interface_methods: interface method array, including methods in the interface and their descriptors; method_name: method name; method_descriptor: method descriptor; jdk_invocations: array of calls to JDK methods; JDKInvocation Object: the same structure as the JDK invocation object in the class; jdk_class_name: JDK Class name; jdk_method_name: JDK method name; jdk_method_descriptor: JDK method descriptor.

[0037] In addition, the difference database can also count the number of various types of minimum difference units and record the reasons for the differences.

[0038] Step 130: determining the minimum difference unit involved according to the involved classes, methods and interfaces and the difference database.

[0039] The classes, methods and interfaces involved obtained in the above steps may be matched with the data in the difference database to determine the minimum difference unit that needs to be adapted in the migration of the application to be migrated.

[0040] Step 140: Use the preset compatibility modification strategy file to search for a corresponding modification strategy according to the minimum difference unit involved.

[0041] For example, the compatibility modification policy file describes in detail the incompatibilities in the application, such as changes in method signatures, removal of methods or fields, modification of access rights, etc. It clearly lists the differences between the old version and the new version, and defines how to perform compatibility repairs through bytecode modification. The corresponding modification policy is obtained by finding the minimum difference unit.

[0042] Step 150: Use the modification strategy to find the location of the minimum difference unit involved, and use the modification strategy to replace the bytecode at the location.

[0043] Bytecode replacement technology is a method to dynamically modify class behavior by manipulating compiled Java bytecodes. It can change class method implementations, add new logic, modify existing calls, etc. at runtime or load time through tools (such as ASM, Javassist, Byte Buddy, etc.). It allows developers to directly manipulate low-level bytecodes to implement changes to deployed code, avoiding tedious modifications and recompilation of source code.

[0044] The position of the minimum difference unit is determined by modifying the descriptions of various incompatible factors defined in the strategy, and the bytecode at the position is replaced using the modification strategy.

[0045] Exemplarily, the replacing the bytecode at the position by using the modification strategy may include:

[0046] When the modification strategy is a method signature change, the bytecode is replaced by inserting type conversion instructions, providing default values ​​for new parameters, adjusting the order of parameters and / or the return type conversion method; and

[0047] When the modification strategy is a class inheritance structure change, the old interface is implemented by generating a proxy for the class, or the bytecode is replaced by simulating the behavior in the old inheritance relationship. The above method can be used to replace the bytecode of the application to be migrated. The modified bytecode can be replaced when the incompatible class is loaded through a loading tool, such as a custom class loader or Java Agent, to ensure that the program runs normally in the new version environment.

[0048] This embodiment decompiles the application to be migrated to obtain the involved classes, methods and interfaces; analyzes the current JDK of the application and the JDK after migration to generate a difference database, in which multiple minimum difference units are recorded; determines the involved minimum difference unit according to the involved classes, methods and interfaces and the difference database; uses a preset compatibility modification strategy file to find the corresponding modification strategy according to the involved minimum difference unit; uses the modification strategy to find the location of the involved minimum difference unit, and uses the modification strategy to replace the bytecode at the location. By analyzing the application to be migrated, the current JDK and the JDK to be migrated, multiple minimum difference units are obtained, and the incompatible factors and corresponding bytecode modification strategies are determined according to the minimum difference units to modify the bytecode. It can effectively deal with compatibility issues caused by version upgrades without modifying the source code or recompiling. Compared with the existing methods, it can effectively reduce the modification workload, quickly and accurately complete the compatibility processing, and is particularly suitable for maintaining large and complex applications.

[0049] Embodiment 2

[0050] Figure 2 It is a flow chart of the Java migration compatibility processing method provided in the second embodiment of the present invention. This embodiment is optimized based on the above embodiment, and uses the modification strategy to find the location of the minimum difference unit involved, and uses the modification strategy to replace the bytecode of the location. The specific optimization is: when the modification strategy is modification, find the global call function of the class in the old version, and locate the replacement position according to the bytecode of the global call function; according to the replacement position, replace the bytecode of the global call function with the bytecode of the updated call function, and insert constant parameters.

[0051] See also Figure 2 , the Java migration compatibility processing method comprises:

[0052] Step 210: Decompile the application to be migrated to obtain the classes, methods and interfaces involved.

[0053] Step 220: Analyze the current JDK and the migrated JDK of the application to generate a difference database, in which a plurality of minimum difference units are recorded.

[0054] Step 230: determining the minimum difference unit involved according to the involved classes, methods and interfaces and the difference database.

[0055] Step 240: Use the preset compatibility modification strategy file to search for the corresponding modification strategy according to the minimum difference unit involved.

[0056] Step 250, when the modification strategy is modification, search for the global call function of the class in the old version, and locate the replacement position according to the bytecode of the global call function.

[0057] By replacing the global call function, the methods in different versions of the class can be replaced. Furthermore, it can also include: changing the class from a public attribute to a private attribute; adding parameters to the method, and setting a wrapper outside the method to facilitate the call of the modified class through reflection.

[0058] The above method can be used to implement a parameterless public method doSomething as the old version method and a parameterized private method doSomething(String param) as the new version method. At the same time, a wrapper method is implemented outside the new method so that it can be used from the outside. This method can be used to simulate the upgrade process of dependent methods in the same dependent class. Modifying a public method to a private method can not only avoid interference with other methods in the class, but also flexibly adjust permissions.

[0059] At the same time, through a wrapper, it is possible to change parameters, such as adding parameters, including adding parameters from no parameters to parameters, and adding parameters based on the original parameters, etc. Realize the reflection call of the new method.

[0060] Step 260: Replace the bytecode of the global calling function with the bytecode of the updated calling function according to the replacement position, and insert constant parameters.

[0061] For example, the main method may be searched first, and the call may be replaced by updating the calling function and passing default parameters, and inserting and modifying the corresponding constant parameters. By using the above method, the bytecode replacement is realized.

[0062] This embodiment uses the modification strategy to find the location of the minimum difference unit involved, and uses the modification strategy to replace the bytecode of the location. The specific optimization is: when the modification strategy is modification, find the global call function of the class in the old version, and locate the replacement position according to the bytecode of the global call function; according to the replacement position, replace the bytecode of the global call function with the bytecode of the updated call function, and insert constant parameters. In some specific scenarios, such as adding parameters, replacing methods, and improving access rights, the methods in the old version can be replaced with the methods of the new version. Bytecode replacement for special cases can be achieved.

[0063] Embodiment 3

[0064] Figure 3is a schematic diagram of the structure of the Java migration compatibility processing device provided by the third embodiment of the present invention, see Figure 3 , the Java migration compatibility processing device comprises:

[0065] An acquisition module 310 is used to decompile the application to be migrated and acquire the classes, methods and interfaces involved;

[0066] A generating module 320 is used to analyze the current JDK and the migrated JDK of the application to generate a difference database, wherein the difference database records a plurality of minimum difference units;

[0067] A determination module 330, configured to determine the minimum difference unit involved according to the involved classes, methods and interfaces and the difference database;

[0068] A search module 340 is used to use a preset compatibility modification strategy file to search for a corresponding modification strategy according to the minimum difference unit involved;

[0069] The replacement module 350 is used to use the modification strategy to find the location of the minimum difference unit involved, and use the modification strategy to replace the bytecode at the location.

[0070] The Java migration compatibility processing device provided in this embodiment obtains the involved classes, methods and interfaces by decompiling the application to be migrated; analyzes the current JDK of the application and the JDK after migration to generate a difference database, in which multiple minimum difference units are recorded; determines the involved minimum difference unit according to the involved classes, methods and interfaces and the difference database; uses a preset compatibility modification strategy file to find the corresponding modification strategy according to the involved minimum difference unit; uses the modification strategy to find the location of the involved minimum difference unit, and uses the modification strategy to replace the bytecode at the location. By analyzing the application to be migrated, the current JDK and the JDK to be migrated, multiple minimum difference units are obtained, and the incompatible factors and corresponding bytecode modification strategies are determined according to the minimum difference units to modify the bytecode. It can effectively deal with compatibility issues caused by version upgrades without modifying the source code or recompiling. Compared with the existing methods, it can effectively reduce the modification workload, quickly and accurately complete the compatibility processing, and is particularly suitable for maintaining large and complex applications.

[0071] Based on the above embodiments, the replacement module includes:

[0072] A positioning unit, used for searching the global call function of the class in the old version when the modification strategy is modification, and locating the replacement position according to the bytecode of the global call function;

[0073] A replacement unit is used to replace the bytecode of the global calling function with the bytecode of the updated calling function according to the replacement position, and insert constant parameters.

[0074] Based on the above embodiments, the replacement module further includes:

[0075] A modification unit, used for modifying the class from a public attribute to a private attribute;

[0076] The setting unit is used to add parameters to the method and set a wrapper outside the method to facilitate calling the modified class through reflection.

[0077] Based on the above embodiments, the generation module includes:

[0078] The extraction unit is used to parse the standard library files in different versions of JDK, extract all classes, methods and fields, and save the information to the API database;

[0079] An analysis unit, configured to use a bytecode analysis engine to perform bytecode analysis on the current JDK and the migrated JDK of the application to obtain an analysis result;

[0080] The compatibility analysis unit is used to perform compatibility analysis of Java classes, methods and interfaces according to the analysis results;

[0081] The generation unit is used to generate a data file for storing incompatible Java classes, methods and interfaces according to the compatibility analysis result.

[0082] Based on the above embodiments, the determining module includes:

[0083] The recording unit is used to record the compatibility status of the classes, methods and interfaces involved in the used JDK core library in the difference database by using each minimum analysis unit.

[0084] Based on the above embodiments, the analysis unit is used for:

[0085] Use the newly added JarBytecodeAnalyzer class to scan the class bytecode in the Java application jar package;

[0086] Use the newly added JClassVisitor class to inherit org.objectweb.asm. Visitor to process the bytecode of each class;

[0087] Use the newly added JMethodVisitor class to inherit org.objectweb.asm.MethodVisitor to process each method in the class bytecode;

[0088] The parsed results are stored using the MethodInvocation entity class to record the class name, method fully qualified name, method descriptor, whether it is an interface tag, and class compatibility status.

[0089] Based on the above embodiments, the replacement module includes:

[0090] The first replacement unit is used to replace the bytecode by inserting type conversion instructions, providing default values ​​for new parameters, adjusting parameter order and / or return type conversion methods when the modification strategy is a method signature change.

[0091] Based on the above embodiments, the replacement module further includes:

[0092] The second replacement unit is used to replace the bytecode by generating a proxy for the class to implement the old interface, or by simulating the behavior in the old inheritance relationship when the modification strategy is a change in the class inheritance structure.

[0093] The Java migration compatibility processing device provided in the embodiment of the present invention can execute the Java migration compatibility processing method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0094] Embodiment 4

[0095] Embodiment 4 of the present invention further provides a storage medium containing computer executable instructions, and when the computer executable instructions are executed by a computer processor, they are used to execute any of the Java migration compatibility processing methods provided in the above embodiments.

[0096] The computer storage medium of the embodiment of the present invention may adopt any combination of one or more computer-readable media. The computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination thereof. More specific examples (non-exhaustive list) of computer-readable storage media include: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium may be any tangible medium containing or storing a program, which may be used by or in combination with an instruction execution system, device or device.

[0097] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, which carry computer-readable program code. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0098] Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0099] Computer program code for performing the operation of the present invention may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or device. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0100] Note that the above are only preferred embodiments of the present invention and the technical principles used. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and that various obvious changes, readjustments and substitutions can be made by those skilled in the art without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in more detail through the above embodiments, the present invention is not limited to the above embodiments, and may include more other equivalent embodiments without departing from the concept of the present invention, and the scope of the present invention is determined by the scope of the appended claims.

Claims

1. A Java migration compatibility processing method, characterized in that: include: Decompile the application to be migrated to obtain the classes, methods, and interfaces involved; Analyze the current JDK and the migrated JDK of the application to generate a difference database, wherein the difference database records a plurality of minimum difference units; Determine the minimum difference unit involved according to the involved classes, methods and interfaces and the difference database, wherein the minimum difference unit can be modified directly without affecting the modification of other minimum difference units; Using a preset compatibility modification strategy file, searching for a corresponding modification strategy according to the minimum difference unit involved; Using the modification strategy to find the location of the minimum difference unit involved, and using the modification strategy to replace the bytecode at the location; The using the modification strategy to find the location of the involved minimum difference unit, and using the modification strategy to replace the bytecode at the location, includes: When the modification strategy is modification, searching for a global call function of the class in the old version, and locating a replacement position according to the bytecode of the global call function; According to the replacement position, the bytecode of the global calling function is replaced with the bytecode of the updated calling function, and constant parameters are inserted; The current JDK and the migrated JDK of the application are analyzed to generate a difference database, wherein the difference database records a plurality of minimum difference units, including: Parse the standard library files in different versions of JDK, extract all classes, methods and fields, and save the information to the API database; Using a bytecode analysis engine to perform bytecode analysis on the current JDK and the migrated JDK of the application to obtain analysis results; According to the analysis results, compatibility analysis of Java classes, methods and interfaces is performed respectively; Generate data files to save incompatible Java classes, methods and interfaces based on compatibility analysis results; The step of replacing the bytecode at the position by using the modification strategy includes: When the modification strategy is a method signature change, the bytecode is replaced by inserting type conversion instructions, providing default values ​​for new parameters, adjusting the order of parameters, and / or returning type conversion methods; Alternatively, when the modification strategy is a change in the class inheritance structure, an old interface is implemented by generating a proxy for the class, or the bytecode is replaced by simulating the behavior in the old inheritance relationship.

2. The method according to claim 1, characterized in that: The method further comprises: Modify the class from a public attribute to a private attribute; New parameters are added to the method, and a wrapper is set outside the method to facilitate calling the modified class through reflection.

3. The method according to claim 1, characterized in that The step of determining the minimum difference unit involved according to the involved classes, methods and interfaces and the difference database comprises: In the difference database, each minimum analysis unit is used to record the compatibility status of the classes, methods, and interfaces involved in the JDK core library used.

4. The method according to claim 1, characterized in that: The bytecode analysis engine is used to perform bytecode analysis on the current JDK and the migrated JDK of the application to obtain analysis results, including: Use the newly added JarBytecodeAnalyzer class to scan the class bytecode in the Java application jar package; Use the newly added JClassVisitor class to inherit org.objectweb.asm.Visitor to process the bytecode of each class; Use the newly added JMethodVisitor class to inherit org.objectweb.asm.MethodVisitor to process each method in the class bytecode; The parsed results are stored using the MethodInvocation entity class to record the class name, method fully qualified name, method descriptor, whether it is an interface tag, and class compatibility status.

5. A Java migration compatibility processing device, characterized in that: include: The acquisition module is used to decompile the application to be migrated and obtain the classes, methods, and interfaces involved; A generation module, used for analyzing the current JDK and the migrated JDK of the application to generate a difference database, wherein the difference database records a plurality of minimum difference units; A determination module, used to determine the minimum difference unit involved according to the involved classes, methods and interfaces and the difference database, wherein the minimum difference unit can be modified directly without affecting the modification of other minimum difference units; A search module, used for searching a corresponding modification strategy according to the minimum difference unit involved by using a preset compatibility modification strategy file; A replacement module, used to use the modification strategy to find the location of the minimum difference unit involved, and replace the bytecode at the location using the modification strategy; The replacement module comprises: A positioning unit, used for searching the global call function of the class in the old version when the modification strategy is modification, and locating the replacement position according to the bytecode of the global call function; A replacement unit, used to replace the bytecode of the global calling function with the bytecode of the updated calling function according to the replacement position, and insert a constant parameter; The replacement module also includes: A first replacement unit is used to replace the bytecode by inserting a type conversion instruction, providing a default value for a newly added parameter, adjusting a parameter order and / or a return type conversion method when the modification strategy is a method signature change; A second replacement unit is used to replace the bytecode by generating a proxy for the class to implement the old interface, or by simulating the behavior in the old inheritance relationship when the modification strategy is a change in the class inheritance structure; The generation module comprises: The extraction unit is used to parse the standard library files in different versions of JDK, extract all classes, methods and fields, and save the information to the API database; An analysis unit, configured to use a bytecode analysis engine to perform bytecode analysis on the current JDK and the migrated JDK of the application to obtain an analysis result; The compatibility analysis unit is used to perform compatibility analysis of Java classes, methods and interfaces according to the analysis results; The generation unit is used to generate a data file for storing incompatible Java classes, methods and interfaces according to the compatibility analysis result.

6. A storage medium containing computer executable instructions, characterized in that: The computer executable instructions are used to execute the Java migration compatibility processing method as described in any one of claims 1 to 4 when executed by a computer processor.

Images