Version adaptation method and device, electronic equipment and storage medium

Abstract

The invention discloses a version adaptation method and device, electronic equipment and a storage medium, and relates to the technical field of computers.The method comprises the steps that a starting class of a current application program is loaded through a preset first class loader, and if it is determined that the type of the current application program is a web application program in the starting class, the current application program is started; obtaining a to-be-adapted jar dependency file in a dependency library directory of the current application program; unpacking the to-be-adapted jar dependent file, and selecting a target byte code file related to class loading; in the search class method of the first class loader, determining a calling position for calling the target bytecode file, and inserting a preset version adaptation method behind the calling position; according to a version adaptation method, performing adaptation processing on the target bytecode file to obtain an adapted bytecode file; and replacing the target byte code file by using the adapted byte code file. By adopting the method and the device, when the adapted byte code file is loaded, the currently running JDK version can be effectively compatible.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular, to a version adaptation method, apparatus, electronic device, and storage medium. Background Art

[0002] In the Java ecosystem, the version iteration of the Java Development Kit (JDK) (such as JDK8, JDK11, JDK17, etc.) continuously introduces new features (such as Lambda expressions, modular systems, Records, etc.) while optimizing the underlying implementation. However, there are significant compatibility issues between application programs compiled with different JDK versions, making it an urgent problem to solve how to adapt programs of different JDK versions. Summary of the Invention

[0003] The present invention provides a version adaptation method, apparatus, electronic device, and storage medium.

[0004] According to one aspect of the present invention, a version adaptation method is provided, including:

[0005] Loading the startup class of the current application through a preset first-class loader, and determining the type of the current application in the startup class;

[0006] In response to the type of the current application being a web application, obtaining the jar dependency file to be adapted in the dependency library directory of the current application;

[0007] Unpacking the jar dependency file to be adapted, and selecting the target bytecode file related to class loading from the bytecode files obtained by the unpacking process;

[0008] In the class finding method of the first-class loader, determining the call position for calling the target bytecode file, and inserting a preset version adaptation method after the call position;

[0009] According to the version adaptation method, performing adaptation processing on the target bytecode file to obtain an adapted bytecode file;

[0010] Replacing the target bytecode file with the adapted bytecode file.

[0011] According to another aspect of the present invention, a version adaptation apparatus is provided, including:

[0012] A program type determination module, configured to load the startup class of the current application through a preset first-class loader, and determine the type of the current application in the startup class;

[0013] A dependent file acquisition module, configured to obtain a to-be-adapted jar dependent file in the dependent library directory of the current application in response to the type of the current application being a web application;

[0014] A bytecode file screening module, configured to unpack the to-be-adapted jar dependent file, and select target bytecode files related to class loading from the bytecode files obtained by the unpacking process;

[0015] A method insertion module, configured to determine a call position for calling the target bytecode file in the class finding method of the first class loader, and insert a preset version adaptation method after the call position;

[0016] An adaptation module, configured to perform an adaptation process on the target bytecode file according to the version adaptation method to obtain an adapted bytecode file;

[0017] A replacement module, configured to replace the target bytecode file with the adapted bytecode file.

[0018] According to another aspect of the present invention, there is provided an electronic device, where the electronic device includes:

[0019] At least one processor; and

[0020] A memory communicatively connected to the at least one processor; wherein,

[0021] The memory stores a computer program executable by the at least one processor, and when the computer program is executed by the at least one processor, the at least one processor is enabled to execute the version adaptation method described in the embodiments of the present invention.

[0022] According to another aspect of the present invention, there is provided a computer-readable storage medium, where the computer-readable storage medium stores computer instructions, and when the computer instructions are executed by a processor, the version adaptation method described in the embodiments of the present invention is implemented.

[0023] The technical solution of the embodiments of the present invention can better be compatible with the currently running JDK version when loading these bytecode files adapted in version.

[0024] It should be understood that the content described in this part is not intended to identify the key or important features of the embodiments of the present invention, nor is it used to limit the scope of the present invention. Other features of the present invention will become easily understood through the following description. Description of the Drawings

[0025] To more clearly illustrate the technical solutions in the embodiments of the present invention, the following will briefly introduce the accompanying drawings required for the description of the embodiments. Obviously, the accompanying drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other accompanying drawings can be obtained based on these drawings.

[0026] Figure 1 It is a schematic flowchart of a version adaptation method provided by an embodiment of the present invention;

[0027] Figure 2 It is a schematic flowchart of a version adaptation method provided by an embodiment of the present invention;

[0028] Figure 3 It is a schematic structural diagram of a version adaptation device provided by an embodiment of the present invention;

[0029] Figure 4 It is a schematic structural diagram of an electronic device for implementing the version adaptation method of the embodiments of the present invention. Specific embodiments

[0030] In order to enable those skilled in the art to better understand the solutions of the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only some of the embodiments of the present invention, rather than all of them. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0031] Embodiment 1

[0032] Figure 1 It is a flowchart of a version adaptation method provided by an embodiment of the present invention. This embodiment is applicable to the scenario of JDK version adaptation of application programs. This method can be executed by a version adaptation device, which can be implemented in the form of hardware and / or software, and the version adaptation device can be configured in an electronic device.

[0033] As Figure 1 shown, the version adaptation method includes:

[0034] S101. Load the startup class of the current application program through a preset first-class loader, and determine the type of the current application program in the startup class.

[0035] In the embodiments of the present invention, the current application program may be a Java application program, and a Java application program refers to a program written based on the Java language. A class loader in Java is responsible for loading the bytecode files of classes into the Java Virtual Machine (JVM), and different class loaders can load classes from different sources. The first class loader of the present invention is specifically set for loading startup classes, that is, the first class loader is a preset class loader for loading the startup classes of the current application program. Startup classes are the classes that are first loaded when the application program starts, and usually contain the entry point of the program (such as the main method in Java), through which the type of the current application program can be determined. The types of the current application program include web application programs and stand-alone application programs. Among them, a web application program refers to a dynamic program accessed through a browser and deployed on the server side, and depends on a Web server to run; a stand-alone application program refers to a Java program that can be directly run on the local operating system.

[0036] In some embodiments, loading the startup class of the current application program through the preset first class loader and determining the type of the current application program in the startup class includes: obtaining an instance of the preset first class loader and using the class loading method of the first class loader instance to load the startup class of the current application program; in the startup class, the type of the application program can be determined through some specific identifiers or configuration information, such as checking a certain static variable in the startup class or a specific field in the configuration file. Exemplarily, if the webserver field is recognized in the startup class, it is determined that the type of the current application program is a web application program, otherwise the type of the current application program is a stand-alone application program.

[0037] S102. In response to the type of the current application program being a web application program, obtain the jar dependency file to be adapted in the dependency library directory of the current application program.

[0038] In the embodiments of the present invention, the dependency library directory refers to a directory for storing external library files (such as jar files) on which the application program depends. The application program needs the classes and resources in these library files to complete specific functions during operation. The jar dependency file includes at least one bytecode file, and each bytecode file is obtained by compiling a class file.

[0039] In some embodiments, in response to the type of the current application being a web application, the type of the web server referenced by the web application is determined, and according to the type of the web server, the jar dependency files corresponding to the type of the web server are searched for in the dependency library directory (i.e., the lib directory) of the application; wherein, the number of Jar dependency files is at least one; furthermore, for each jar dependency file, the bytecode file is read therefrom, and the compilation version of each bytecode file is determined, where the compilation version of the bytecode file refers to the JDK version used when compiling the bytecode file; the compilation version of each bytecode file is compared with the JDK version on which the current application runs, and if they are inconsistent, it is determined that this jar dependency file is the jar dependency file to be adapted; wherein, the way to obtain the compilation version of the bytecode file is: obtain the header information of the bytecode file, and determine the major version number according to the header information, and this major version number corresponds to the JDK version used when compiling this class.

[0040] S103. Unpack the jar dependency file to be adapted, and select the target bytecode files related to class loading from the bytecode files obtained from the unpacking process.

[0041] In the embodiments of the present invention, the unpacking process is to decompress the jar dependency file and extract the bytecode files and other contents therein, so as to operate on the bytecode files subsequently. The bytecode file is the class file generated after the Java source file is compiled, and contains the bytecode instructions that can be executed by the Java virtual machine. The target bytecode files are the files related to class loading selected from the unpacked bytecode files, and these files are the main objects for version adaptation.

[0042] In the embodiments of the present invention, when the type of the current application is determined to be a Web application in the Java startup class, and it is further determined that the version of the jar dependency file is incompatible with the JDK version on which the current application runs, it is necessary to perform an unpacking operation on the relevant jar dependency files. The purpose of unpacking is to directly obtain the respective bytecode files therein, which is convenient for subsequent adaptation processing.

[0043] In some embodiments, classes in the java.util.zip package of Java (such as ZipInputStream) are used to decompress the jar dependency files, and contents such as bytecode files are extracted into a specified temporary directory. Then, by analyzing the contents or class names of the bytecode files, etc., the target bytecode files related to class loading are filtered out. For example, filtering can be performed by checking whether the class name contains specific keywords or analyzing whether the method calls in the bytecode files are related to class loading. In specific implementation, the target bytecode files related to class loading are selected from the bytecode files obtained by unpacking processing, including: for any bytecode file obtained by unpacking processing, if the file name of the bytecode file contains a specified character or the bytecode file inherits from a specified class, then the bytecode file is used as the target bytecode file; wherein, the specified character is classloader, and the specified class is the ClassLoader class.

[0044] S104. In the class finding method of the first class loader, determine the call location of the target bytecode file, and insert a pre-set version adaptation method after the call location.

[0045] In the embodiments of the present invention, the class finding method (i.e., the findClass method) is a method in the first class loader for finding a specified class. The call location of the target bytecode file is determined in this method. The version adaptation method is a pre-set method for performing JDK version adaptation on the target bytecode file, mainly to solve the compatibility problem between different JDK versions by modifying the bytecode file.

[0046] In some embodiments, in the class finding method of the first class loader, determining the call location of the target bytecode file and inserting a pre-set version adaptation method after the call location includes: First, use a bytecode analysis tool to locate the location of the call to the target bytecode file. Then, insert the bytecode of the pre-written version adaptation method after this location. In specific implementation, it is necessary to convert the bytecode of the version adaptation method into a format suitable for insertion into the class finding method and perform corresponding bytecode splicing operations.

[0047] S105. According to the version adaptation method, perform adaptation processing on the target bytecode file to obtain an adapted bytecode file.

[0048] In the embodiments of the present invention, the adapted bytecode file refers to the bytecode file obtained after being processed by the version adaptation method, which solves the version compatibility problem and can be used normally in the current environment.

[0049] In some embodiments, the version adaptation method may be called in the class lookup method of the first - type loader. The version adaptation method performs specific adaptation processing on the target bytecode file, that is, takes the target bytecode file as the input of the version adaptation method, and the output of the version adaptation method is the adapted bytecode file. The adaptation processing may include modifying the constant pool, method calls, class inheritance relationships, etc. in the bytecode file to solve the compatibility problems between different JDK versions. After the processing is completed, the adapted bytecode file is generated.

[0050] S106. Use the adapted bytecode file to replace the target bytecode file.

[0051] In the embodiments of the present invention, the original target bytecode file is overwritten with the adapted bytecode file. The adapted bytecode file can be written to the storage location of the original target bytecode file through file system operations to complete the replacement operation. In this way, in the subsequent class loading process, the adapted bytecode file will be used, thus solving the JDK version compatibility problem.

[0052] The technical solution of the embodiments of the present invention can better be compatible with the currently running JDK version when loading these bytecode files adapted by version.

[0053] Embodiment 2

[0054] Figure 2 It is a flowchart of a version adaptation method provided by an embodiment of the present invention. Refer to Figure 2 , the version adaptation method includes the following steps:

[0055] S201. Construct a folder named with the JDK version number under the resource directory of the current application, and construct a version decision tree in the folder.

[0056] In the embodiments of the present invention, the constructed version decision tree includes a root node, secondary nodes, and tertiary nodes; among them, the root node is usually the JDK version number, which is the starting point of the entire decision tree. The secondary nodes represent relative versions, that is, the difference information compared with the root node version. For example, compared with JDK 11 (the root node version), JDK 8 and JDK 17 have differences in language features, class library functions, etc., and these differences will be reflected in the secondary nodes. It can be described as "missing certain features from JDK 11 to JDK 8" or "newly added certain features from JDK 11 to JDK 17", etc. The tertiary nodes, that is, the child nodes, are composed of different feature values and their classifications. The feature value refers to the specific aspects that may differ between different JDK versions, such as syntax features (such as Lambda expressions, sealed classes, etc.), class library functions (such as the use of the HTTP client API), etc. Each feature value can have different classifications. For example, a certain syntax feature may have two classifications: supported and not supported. Feature value classification: Under each feature value classification, prompts for large model search will be defined. These prompts are used to provide clear search directions and task descriptions for the large model when code generation or adaptation needs to be assisted by the large model. For example, for a specific syntax feature, the prompt can be "generate code to implement a function similar to the Lambda expression in the JDK 8 environment".

[0057] S202. Load the startup class of the current application through a preset first-class loader, and determine the type of the current application in the startup class.

[0058] S203. In response to the type of the current application being a web application, obtain the jar dependency file to be adapted under the dependency library directory of the current application.

[0059] S204. Unpack the jar dependency file to be adapted, and select the target bytecode file related to class loading from the bytecode files obtained from the unpacking process.

[0060] S205. In the class-finding method of the first-class loader, determine the call location for calling the target bytecode file, and insert a preset version adaptation method after the call location.

[0061] In the embodiments of the present invention, the specific implementation processes of steps S202 - S205 can be referred to the descriptions of the above embodiments, and will not be elaborated here.

[0062] S206. According to the version adaptation method, perform adaptation processing on the target bytecode file to obtain the adapted bytecode file.

[0063] In some embodiments, according to the version adaptation method, the target bytecode file is adaptively processed to obtain the adaptively processed bytecode file, including steps A - E:

[0064] A. Pre - load the target bytecode file through a preset second - type class loader.

[0065] In the embodiments of the present invention, the second - type class loader is optionally a custom debugging class loader for pre - loading the target bytecode file. After the target bytecode file is passed as the input of the version adaptation method, the target bytecode file is pre - loaded through the defineClass method of the second - type class loader. If there is no error in the loading process of the target bytecode file, it is determined that the target bytecode file does not need to be adapted. If the pre - loading fails, step B is executed.

[0066] B. In response to an error occurring in the loading process of the target bytecode file, extract the JDK version used when compiling the target bytecode file from the target bytecode file.

[0067] If an error occurs during the pre - loading of the target bytecode, it is determined that the compilation version of the target bytecode is not compatible with the JDK version used by the virtual machine running the current application. The target bytecode needs to be adaptively processed. Specifically, the JDK version used when compiling the target bytecode file can be extracted from the target bytecode file first.

[0068] C. Determine the version distance and adaptation direction according to the JDK version used when compiling the target bytecode file and the JDK version used by the virtual machine running the current application.

[0069] In some embodiments, subtract the JDK version used when compiling the target bytecode file from the JDK version used by the virtual machine running the current application to obtain the version distance; for example, if the JDK version used by the virtual machine running the current application is JDK11 and the JDK version used when compiling the target bytecode file is JDK8, the version distance is 3. If the version distance is positive, version upgrade is required, that is, the adaptation direction is upgrade; if it is negative, version downgrade is required, and the adaptation direction is determined to be downgrade.

[0070] D. Obtain the corresponding version decision tree according to the version distance and adaptation direction; among them, the version decision tree is pre - constructed and stored, including the characteristic differences between different JDK versions.

[0071] For example, if it is determined according to the version distance and adaptation direction that an upgrade from JDK8 to JDK11 is required, version decision trees with root nodes JDK8, JDK9, and JDK10 need to be obtained.

[0072] E. Based on the version decision tree, perform adaptation processing on the target bytecode file to obtain the adapted bytecode file.

[0073] In some embodiments, perform feature matching between the target bytecode file and the version decision tree to obtain at least one feature matching result, which can be stored in a pre-constructed feature value container; wherein, each feature matching result includes a bytecode matching point, a version feature value, and a prompt word for instructing the large model to generate adaptation code according to the version feature value; wherein, the bytecode matching point refers to a specific position in the target bytecode that matches the version decision tree feature. These specific positions usually correspond to a certain method, instruction sequence, or specific part of a class in the bytecode. During the version adaptation process, by searching for the bytecode matching point, it can be determined which parts of the bytecode need to be modified or replaced according to the characteristics of different JDK versions. For any feature matching result, parse the method where the bytecode matching point is located, and convert the method bytecode corresponding to the method into method source code; input the prompt word into the large model and obtain the adaptation code output by the large model; fuse the method source code and the adaptation code to obtain the method adaptation code; convert the method adaptation code into method adaptation bytecode, and use the method adaptation bytecode to adapt and replace the method bytecode in the target bytecode file to obtain the adapted bytecode file.

[0074] The process of using the adapted bytecode file to replace the target bytecode file can refer to step S207.

[0075] S207. Preload the adapted bytecode file through a preset second-class loader; if the preloading is successful, use the adapted bytecode file to replace the target bytecode file.

[0076] In the embodiments of the present invention, if the successful preloading of the adapted bytecode file is completed through the preset second-class loader, it indicates that the adapted bytecode file is compatible with the JDK version used by the current application, and only the adapted bytecode file needs to be used to replace the target bytecode file. If the preloading of the adapted bytecode file fails, it indicates that the adapted bytecode file is not compatible with the JDK version used by the current application. At this time, the bytecode can be located according to the error message, the feature value can be reversely searched for calibration, and then the version adaptation can be tried again.

[0077] Adopting the solution of the present invention, the bytecode files in the jar dependency files can be adapted to the JDK version, so that when loading these bytecode files adapted to the version, they can better be compatible with the currently running JDK version.

[0078] Embodiment III

[0079] Figure 3The structural schematic diagram of a version adaptation device provided by an embodiment of the present invention. This embodiment is applicable to the scenario of JDK version adaptation of application programs. As Figure 3 shown, the device includes:

[0080] A program type determination module 301, configured to load the startup class of the current application program through a preset first-class loader, and determine the type of the current application program in the startup class;

[0081] A dependent file acquisition module 302, configured to, in response to the type of the current application program being a web application program, acquire a jar dependent file to be adapted in the dependent library directory of the current application program;

[0082] A bytecode file screening module 303, configured to unpack the jar dependent file to be adapted, and select target bytecode files related to class loading from the bytecode files obtained by the unpacking process;

[0083] A method insertion module 304, configured to determine a call position for calling the target bytecode file in the class finding method of the first-class loader, and insert a preset version adaptation method after the call position;

[0084] An adaptation module 305, configured to perform adaptation processing on the target bytecode file according to the version adaptation method to obtain an adapted bytecode file;

[0085] A replacement module 306, configured to replace the target bytecode file with the adapted bytecode file.

[0086] In some embodiments, in terms of performing adaptation processing on the target bytecode file according to the version adaptation method to obtain an adapted bytecode file, the adaptation module 305 includes:

[0087] A loading unit, configured to pre-load the target bytecode file through a preset second-class loader;

[0088] An extraction unit, configured to, in response to an error occurring during the loading process of the target bytecode file, extract the JDK version used when compiling the target bytecode file from the target bytecode file;

[0089] A comparison unit, configured to determine a version distance and an adaptation direction according to the JDK version used when compiling the target bytecode file and the JDK version used by the virtual machine running the current application program;

[0090] A decision tree acquisition unit, configured to acquire a corresponding version decision tree according to the version distance and the adaptation direction; wherein, the version decision tree is pre-constructed and stored, and includes the characteristic differences between different JDK versions;

[0091] An adaptation unit for adaptively processing a target bytecode file based on a version decision tree to obtain an adapted bytecode file.

[0092] In some embodiments, in terms of adaptively processing a target bytecode file based on a version decision tree to obtain an adapted bytecode file, the adaptation unit is specifically configured to:

[0093] Perform feature matching between the target bytecode file and the version decision tree to obtain at least one feature matching result; wherein each feature matching result includes a bytecode matching point, a version feature value, and a prompt word for instructing the large model to generate adaptation code according to the version feature value;

[0094] For any feature matching result, parse the method where the bytecode matching point is located, and convert the method bytecode corresponding to the method into method source code;

[0095] Input the prompt word into the large model and obtain the adaptation code output by the large model;

[0096] Fuse the method source code and the adaptation code to obtain method adaptation code;

[0097] Convert the method adaptation code into method adaptation bytecode, and use the method adaptation bytecode to adaptively replace the method bytecode in the target bytecode file to obtain an adapted bytecode file.

[0098] In some embodiments, using the adapted bytecode file to replace the target bytecode file includes:

[0099] Pre-load the adapted bytecode file through a preset second-class loader;

[0100] If the pre-loading is successful, use the adapted bytecode file to replace the target bytecode file.

[0101] In some embodiments, it further includes:

[0102] An adaptation judgment module for determining that the target bytecode file does not need to be adapted in response to the loading process of the target bytecode file not having an error.

[0103] In some embodiments, it further includes a decision tree construction module for:

[0104] Construct a folder named with the JDK version number under the resource directory of the current application;

[0105] Build a version decision tree in a folder; wherein, the root node of the version decision tree is the JDK version number, the secondary nodes are the difference information between the root node JDK version and other JDK versions, and the tertiary nodes include the specific eigenvalue, eigenvalue classification of the differences between different JDK versions, and the prompt words defined under the eigenvalue classification for large model search.

[0106] In some embodiments, in terms of selecting the target bytecode file related to class loading from the bytecode files obtained by unpacking, the bytecode file screening module 303 is further configured to:

[0107] For any bytecode file obtained by unpacking, if the file name of the bytecode file contains a specified character or the bytecode file inherits from a specified class, then the bytecode file is used as the target bytecode file; wherein, the specified character is classloader, and the specified class is the ClassLoader class.

[0108] The version adaptation device provided by the embodiments of the present invention can execute the version adaptation method provided by any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0109] Embodiment 4

[0110] Figure 4 FIG. shows a schematic structural diagram of an electronic device 10 that can be used to implement the embodiments of the present invention. The electronic device is intended to represent various forms of digital computers, such as, laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as, personal digital processing, cellular phones, smart phones, wearable devices (such as helmets, glasses, watches, etc.) and other similar computing devices. The components shown herein, their connections and relationships, and their functions are only examples and are not intended to limit the implementation of the present invention described and / or claimed herein.

[0111] As Figure 4As shown, the electronic device 10 includes at least one processor 11 and a memory communicatively connected to the at least one processor 11, such as a read-only memory (ROM) 12, a random access memory (RAM) 13, etc. Among them, the memory stores a computer program executable by the at least one processor. The processor 11 can perform various appropriate actions and processes according to the computer program stored in the read-only memory (ROM) 12 or the computer program loaded from the storage unit 18 into the random access memory (RAM) 13. In the RAM 13, various programs and data required for the operation of the electronic device 10 can also be stored. The processor 11, the ROM 12, and the RAM 13 are connected to each other through a bus 14. The input / output (I / O) interface 15 is also connected to the bus 14.

[0112] Multiple components in the electronic device 10 are connected to the I / O interface 15, including: an input unit 16, such as a keyboard, a mouse, etc.; an output unit 17, such as various types of displays, speakers, etc.; a storage unit 18, such as a disk, an optical disc, etc.; and a communication unit 19, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 19 allows the electronic device 10 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks.

[0113] The processor 11 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the processor 11 include but are not limited to a central processing unit (CPU), a graphics processing unit (GPU), various dedicated artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. The processor 11 executes the various methods and processes described above, such as executing the version adaptation method.

[0114] In some embodiments, the version adaptation method can be implemented as a computer program, which is tangibly contained in a computer-readable storage medium, such as the storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed onto the electronic device 10 via the ROM 12 and / or the communication unit 19. When the computer program is loaded into the RAM 13 and executed by the processor 11, one or more steps of the version adaptation method described above can be executed. Alternatively, in other embodiments, the processor 11 can be configured to execute the version adaptation method in any other appropriate manner (e.g., by means of firmware).

[0115] The various embodiments of the systems and techniques described above in this specification can be implemented in digital electronic circuitry, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems-on-chip (SOCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments can include: being implemented in one or more computer programs that are executable and / or interpretable on a programmable system including at least one programmable processor, which can be a special-purpose or general-purpose programmable processor that receives data and instructions from, and transmits data and instructions to, a storage system, at least one input device, and at least one output device.

[0116] The computer programs for implementing the methods of the present invention can be written in any combination of one or more programming languages. These computer programs can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the computer programs, when executed by the processor, cause the functions / operations specified in the flowchart and / or block diagram to be implemented. The computer programs can be executed entirely on the machine, partly on the machine, as a stand-alone software package partly on the machine and partly on a remote machine or entirely on the remote machine or server.

[0117] In the context of the present invention, a computer-readable storage medium can be a tangible medium that can contain, or store a computer program for use by or in connection with an instruction execution system, apparatus, or device. The computer-readable storage medium can include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. Alternatively, the computer-readable storage medium can be a machine-readable signal medium. More specific examples of the machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, 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 disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0118] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and a pointing device (e.g., a mouse or a trackball) through which the user can provide input to the electronic device. Other kinds of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic input, voice input, or tactile input).

[0119] The systems and techniques described herein can be implemented in a computing system including backend components (e.g., as a data server), or a computing system including middleware components (e.g., an application server), or a computing system including frontend components (e.g., a user computer having a graphical user interface or a web browser through which the user can interact with an implementation of the systems and techniques described herein), or a computing system including any combination of such backend components, middleware components, or frontend components. The components of the system can be interconnected to each other by digital data communication in any form or medium (e.g., a communication network). Examples of communication networks include: local area network (LAN), wide area network (WAN), blockchain network, and the Internet.

[0120] The computing system can include a client and a server. The client and the server are generally remote from each other and typically interact through a communication network. The relationship between the client and the server is generated by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or a cloud host, which is a host product in the cloud computing service system and solves the defects of difficult management and weak business scalability existing in traditional physical hosts and VPS services.

[0121] It should be understood that various forms of the processes shown above can be used, with steps reordered, added, or deleted. For example, the steps recited in the present invention can be executed in parallel, sequentially, or in a different order, as long as the desired results of the technical solution of the present invention can be achieved, and no limitation is imposed herein.

[0122] The above specific embodiments do not constitute a limitation on the protection scope of the present invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention shall be included within the protection scope of the present invention.

Claims

1. A version adaptation method, characterized in that, including: loading the startup class of the current application through a preset first-class loader, and determining the type of the current application in the startup class; in response to the type of the current application being a web application, obtaining a jar dependency file to be adapted under the dependency library directory of the current application; unpacking the jar dependency file to be adapted, and selecting target bytecode files related to class loading from the bytecode files obtained by the unpacking process; in the class-finding method of the first-class loader, determining the call location for calling the target bytecode file, and inserting a preset version adaptation method after the call location; performing adaptation processing on the target bytecode file according to the version adaptation method to obtain an adapted bytecode file; replacing the target bytecode file with the adapted bytecode file.

2. The method according to claim 1, wherein The performing adaptation processing on the target bytecode file according to the version adaptation method to obtain an adapted bytecode file includes: preloading the target bytecode file through a preset second-class loader; in response to an error occurring during the loading process of the target bytecode file, extracting the JDK version used when compiling the target bytecode file from the target bytecode file; determining the version distance and adaptation direction according to the JDK version used when compiling the target bytecode file and the JDK version used by the virtual machine running the current application; obtaining a corresponding version decision tree according to the version distance and the adaptation direction; wherein the version decision tree is pre-constructed and stored, and includes the feature differences between different JDK versions; performing adaptation processing on the target bytecode file based on the version decision tree to obtain an adapted bytecode file.

3. The method according to claim 2, wherein The performing adaptation processing on the target bytecode file based on the version decision tree to obtain an adapted bytecode file includes: performing feature matching between the target bytecode file and the version decision tree to obtain at least one feature matching result; wherein each feature matching result includes a bytecode matching point, a version feature value, and a prompt word for instructing the large model to generate adaptation code according to the version feature value; for any feature matching result, parsing the method where the bytecode matching point is located, and converting the method bytecode corresponding to the method into method source code; inputting the prompt word into the large model, and obtaining the adaptation code output by the large model; fusing the method source code and the adaptation code to obtain method adaptation code; converting the method adaptation code into method adaptation bytecode, and using the method adaptation bytecode to perform adaptation replacement on the method bytecode in the target bytecode file to obtain the adapted bytecode file.

4. The method according to claim 3, wherein The replacing the target bytecode file with the adapted bytecode file includes: preloading the adapted bytecode file through a preset second-class loader; if the preloading is successful, replacing the target bytecode file with the adapted bytecode file.

5. The method according to claim 2, characterized in that, It also includes: In response to the loading process of the target bytecode file not having an error, it is determined that the target bytecode file does not need to be adapted.

6. The method according to claim 3, wherein It further includes: Construct a folder named with the JDK version number under the resource directory of the current application; Construct a version decision tree in the folder; wherein, the root node of the version decision tree is the JDK version number, the secondary nodes are the difference information between the root node JDK version and other JDK versions, the tertiary nodes include the specific eigenvalue differences between different JDK versions, eigenvalue classifications, and the prompt words defined under the eigenvalue classifications for large model search.

7. The method according to claim 1, characterized in that, The selecting of the target bytecode file related to class loading from the bytecode files obtained by unpacking processing includes: For any bytecode file obtained by unpacking processing, if the file name of the bytecode file contains the specified character or the bytecode file inherits from the specified class, then the bytecode file is used as the target bytecode file; wherein, the specified character is "classloader", and the specified class is the ClassLoader class.

8. An adaptation device for versions, characterized in that, It includes: A program type determination module, configured to load the startup class of the current application through a preset first class loader and determine the type of the current application in the startup class; A dependent file acquisition module, configured to, in response to the type of the current application being a web application, acquire the jar dependent files to be adapted under the dependent library directory of the current application; A bytecode file screening module, configured to perform unpacking processing on the jar dependent files to be adapted and select the target bytecode files related to class loading from the bytecode files obtained by unpacking processing; A method insertion module, configured to determine the call position for calling the target bytecode file in the class finding method of the first class loader and insert a preset version adaptation method after the call position; An adaptation module, configured to perform adaptation processing on the target bytecode file according to the version adaptation method to obtain an adapted bytecode file; A replacement module, configured to replace the target bytecode file with the adapted bytecode file.

9. An electronic device, characterized in that, It includes: At least one processor; And A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions, and the computer instructions are used to cause the processor to implement the method according to any one of claims 1-7 when executed.

Images