Version adaptation method, device, electronic device and storage medium

Abstract

The present invention discloses a version adaptation method, device, electronic device, and storage medium, relating to the field of computer technology. The method comprises: loading the startup class of the current application through a preset first class loader; if the type of the current application is determined to be a web application in the startup class, obtaining a jar dependency file to be adapted from the dependency library directory of the current application; unpacking the jar dependency file to be adapted and selecting a target bytecode file related to class loading; determining a call location for calling the target bytecode file in a search class method of the first class loader, and inserting a preset version adaptation method after the call location; adapting the target bytecode file according to the version adaptation method to obtain an adapted bytecode file; and replacing the target bytecode file with the adapted bytecode file. The present invention effectively achieves compatibility with the currently running JDK version when loading the adapted bytecode file.

Description

Technical Field

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

[0002] In the Java ecosystem, successive Java Development Kit (JDK) versions (e.g., JDK8, JDK11, JDK17, etc.) continue to introduce new features (such as Lambda expressions, the module system, and Records) while optimizing underlying implementations. However, applications compiled with different JDK versions often face significant compatibility issues, making adapting programs across different JDK versions a pressing issue. Summary of the Invention

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

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

[0005] Load the startup class of the current application through the preset first class loader, and determine 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 a jar dependency file to be adapted in a dependency library directory of the current application;

[0007] Unpack the jar dependency file to be adapted, and select the target bytecode file related to class loading from the bytecode file obtained by unpacking;

[0008] In the search class method of the first class loader, a calling position of the target bytecode file is determined, and a pre-set version adaptation method is inserted after the calling position;

[0009] According to the version adaptation method, the target bytecode file is adapted to obtain the adapted bytecode file;

[0010] The target bytecode file is replaced with the adapted bytecode file.

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

[0012] A program type determination module, 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;

[0013] A dependency file acquisition module is used to obtain the jar dependency file to be adapted in the dependency library directory of the current application in response to the type of the current application being a web application;

[0014] The bytecode file screening module is used to unpack the jar dependency files to be adapted and select the target bytecode files related to class loading from the unpacked bytecode files;

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

[0016] The adaptation module is used to adapt the target bytecode file according to the version adaptation method to obtain the adapted bytecode file;

[0017] The replacement module is used to replace the target bytecode file with the adapted bytecode file.

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

[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 that can be executed by the at least one processor. The computer program is executed by the at least one processor to enable the at least one processor to perform the version adaptation method described in the embodiment of the present invention.

[0022] According to another aspect of the present invention, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the version adaptation method described in an embodiment of the present invention when executed.

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

[0024] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present invention, nor is it intended to limit the scope of the present invention. Other features of the present invention will become readily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0026] Figure 1 is a flowchart of a version adaptation method provided according to an embodiment of the present invention;

[0027] Figure 2 is a flowchart of a version adaptation method provided according to an embodiment of the present invention;

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

[0029] Figure 4 It is a structural diagram of an electronic device that implements the version adaptation method of an embodiment of the present invention. DETAILED DESCRIPTION

[0030] In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of the present invention.

[0031] Example 1

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

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

[0034] S101: 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.

[0035] In an embodiment of the present invention, the current application may optionally be a Java application, and a Java application refers to a program written in Java. In Java, the class loader is responsible for loading the bytecode file of a class 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 specially set up to load the startup class, that is, the first class loader is a preset class loader for loading the startup class of the current application. The startup class is the first class loaded when the application starts, and usually contains the entry point of the program (such as the main method in Java), through which the type of the current application can be determined. The types of current applications include web applications and standalone applications, among which web applications refer to dynamic programs deployed on the server side that are accessed through a browser and rely on a web server to run; standalone applications refer to Java programs that can be run directly on the local operating system.

[0036] In some embodiments, 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 includes: obtaining a preset first class loader instance and using the load class method of the first class loader instance to load the startup class of the current application; in the startup class, the type of the application can be determined by some specific identification or configuration information, such as checking a static variable in the startup class or a specific field in a configuration file. For example, if the webserver field is identified in the startup class, the type of the current application is determined to be a web application; otherwise, the type of the current application is determined to be a standalone application.

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

[0038] In this embodiment of the present invention, a dependency library directory refers to a directory that stores external library files (such as JAR files) that an application depends on. During runtime, the application requires the classes and resources in these library files to perform specific functions. A JAR dependency file includes at least one bytecode file, each of which is compiled from a class file.

[0039] In some embodiments, in response to the current application being a web application, the web server type referenced by the web application is determined, and based on the web server type, a jar dependency file corresponding to the web server type is searched in the application's dependency library directory (i.e., lib directory); wherein, the number of Jar dependency files is at least one; and then, for each jar dependency file, the bytecode file is read therefrom, and the compiled version of each bytecode file is determined, wherein the compiled version of the bytecode file refers to the JDK version used when compiling the bytecode file; the compiled version of each bytecode file is compared with the JDK version running the current application, and if they are inconsistent, the jar dependency file is determined to be the jar dependency file to be adapted; wherein, the compiled version of the bytecode file is obtained by obtaining the header information of the bytecode file, and determining the major version number based on the header information, and the major version number corresponds to the JDK version used when compiling the class.

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

[0041] In this embodiment of the present invention, unpacking involves decompressing the JAR dependency files and extracting their contents, including bytecode files, to facilitate subsequent operations on the bytecode files. Bytecode files are class files generated after compiling Java source files and contain bytecode instructions executable by the Java Virtual Machine. Target bytecode files are files related to class loading selected from the unpacked bytecode files and are the primary targets for version adaptation.

[0042] In this embodiment of the present invention, when the Java startup class determines the current application type as a web application and further determines that the version of the JAR dependency files is incompatible with the currently running JDK version, it is necessary to unpack the relevant JAR dependency files. The purpose of unpacking is to directly obtain the individual bytecode files therein, facilitating subsequent adaptation processing.

[0043] In some embodiments, a class in Java's java.util.zip package (such as ZipInputStream) is used to decompress the jar dependency file, and the bytecode file and other contents therein are extracted to a specified temporary directory. Then, by analyzing the content of the bytecode file or information such as the class name, the target bytecode file related to class loading is screened out. For example, the screening can be performed by checking whether the class name contains specific keywords or analyzing whether the method call in the bytecode file is related to class loading. In a specific implementation, the target bytecode file related to class loading is selected from the bytecode file obtained by the unpacking process, including: for any bytecode file obtained by the unpacking process, if the file name of the bytecode file contains specified characters or the bytecode file inherits from a specified class, then the bytecode file is used as the target bytecode file; wherein the specified characters are classloader and the specified class is the ClassLoader class.

[0044] S104. In the search class method of the first class loader, determine the calling position of the target bytecode file, and insert a preset version adaptation method after the calling position.

[0045] In this embodiment of the present invention, the findClass method is a method within the first class loader that searches for a specified class. This method determines the location of the target bytecode file. The version adaptation method is a predefined method for adapting the target bytecode file to the JDK version. This method primarily addresses compatibility issues between different JDK versions by modifying the bytecode file.

[0046] In some embodiments, in a search class method of a first class loader, a call location for calling a target bytecode file is determined, and a pre-set version adaptation method is inserted after the call location, including: first, locating the location where the target bytecode file is called using a bytecode analysis tool. Then, the bytecode of the pre-written version adaptation method is inserted after the location. In a specific implementation, the bytecode of the version adaptation method needs to be converted into a format suitable for insertion into the search class method, and a corresponding bytecode splicing operation needs to be performed.

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

[0048] In the embodiment of the present invention, the adapted bytecode file refers to a 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, a version adaptation method can be called within the first class loader's search class method. This version adaptation method performs specific adaptation processing on the target bytecode file. Specifically, the target bytecode file is used as input to the version adaptation method, and the output of the version adaptation method is an adapted bytecode file. The adaptation process may include modifying the constant pool, method calls, class inheritance relationships, and other aspects of the bytecode file to address compatibility issues between different JDK versions. After the process is complete, an adapted bytecode file is generated.

[0050] S106: Replace the target bytecode file with the adapted bytecode file.

[0051] In this embodiment of the present invention, the adapted bytecode file overwrites the original target 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. This allows the adapted bytecode file to be used during subsequent class loading, thereby resolving JDK version compatibility issues.

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

[0053] Example 2

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

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

[0056] In this embodiment of the present invention, the constructed version decision tree consists of a root node, second-level nodes, and third-level nodes. The root node is typically the JDK version number and serves as the starting point for the entire decision tree. Second-level nodes represent relative versions, that is, differences from the root node version. For example, compared to JDK 11 (the root node version), JDK 8 and JDK 17 differ in language features, library functionality, and other aspects. These differences are reflected in the second-level nodes. These differences can be described as "certain features are missing from JDK 11 to JDK 8" or "certain features are added from JDK 11 to JDK 17." Third-level nodes, or child nodes, are composed of different feature values ​​and their classifications. Feature values ​​refer to specific aspects that may differ between JDK versions, such as syntax features (such as Lambda expressions and sealed classes) and library functionality (such as the use of HTTP client APIs). Each feature value can have different classifications; for example, a syntax feature may be classified as either supported or unsupported. Feature value classification: Within each feature value classification, a prompt word is defined for large model search. These prompts are used to provide clear search directions and task descriptions for large models when code generation or adaptation is required. For example, for a specific syntax feature, a prompt might be "Generate code that implements Lambda expression-like functionality in the JDK8 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 a jar dependency file to be adapted in a dependency library directory of the current application.

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

[0060] S205. In the search class method of the first class loader, determine the calling position of the target bytecode file, and insert a preset version adaptation method after the calling position.

[0061] In the embodiment of the present invention, the specific implementation process of steps S202-S205 can be found in the description of the above embodiment and will not be repeated here.

[0062] S206: According to the version adaptation method, the target bytecode file is adapted to obtain an adapted bytecode file.

[0063] In some embodiments, according to the version adaptation method, the target bytecode file is adapted to obtain an adapted bytecode file, including steps AE:

[0064] A. Preload the target bytecode file through the preset second class loader.

[0065] In an embodiment of the present invention, the second class loader may optionally be a custom debug class loader for preloading the target bytecode file. After the target bytecode file is passed as input to the version adaptation method, the target bytecode file is preloaded via the defineClass method of the second class loader. If no error occurs during the loading of the target bytecode file, it is determined that the target bytecode file does not require adaptation. If an error occurs during the preloading process, step B is executed.

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

[0067] If an error occurs during target bytecode preloading, it is determined that the compiled version of the target bytecode is incompatible with the JDK version used by the virtual machine running the current application. The target bytecode needs to be adapted. To implement this, you can first extract the JDK version used to compile the target bytecode file from the target bytecode file.

[0068] C. Determine the version distance and adaptation direction based on 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, the version distance is calculated by subtracting the JDK version used when compiling the target bytecode file from the JDK version used by the virtual machine running the current application. 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, a version upgrade is required, and the adaptation direction is upgrade. If it is negative, a version downgrade is required, and the adaptation direction is determined to be downgrade.

[0070] D. Obtain the corresponding version decision tree based on the version distance and adaptation direction. The version decision tree is pre-built and stored, including the feature differences between different JDK versions.

[0071] For example, if it is determined based on the version distance and the adaptation direction that JDK8 needs to be upgraded to JDK11, it is necessary to obtain a version decision tree whose root nodes are JDK8, JDK9, and JDK10 respectively.

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

[0073] In some embodiments, a target bytecode file is feature-matched against a version decision tree to obtain at least one feature matching result. The feature matching result can be stored in a pre-built feature value container. Each feature matching result includes a bytecode matching point, a version feature value, and a prompt word that instructs the large model to generate adaptation code based on the version feature value. A bytecode matching point refers to a specific location in the target bytecode that matches a feature from the version decision tree. These specific locations typically correspond to a method, instruction sequence, or specific portion of a class in the bytecode. During the version adaptation process, by searching for bytecode matching points, it is possible to determine which bytecode portions need to be modified or replaced based on the characteristics of different JDK versions. For each feature matching result, the method corresponding to the bytecode matching point is parsed, and the corresponding method bytecode is converted into method source code. The prompt word is input into the large model, and the adaptation code output by the large model is obtained. The method source code is merged with the adaptation code to obtain method adaptation code. The method adaptation code is converted into method adaptation bytecode, and the method adaptation bytecode is used to adapt and replace the method bytecode in the target bytecode file to obtain an adapted bytecode file.

[0074] The process of replacing the target bytecode file with the adapted bytecode file can be seen in step S207.

[0075] S207 , 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.

[0076] In this embodiment of the present invention, if the preloading of the adapted bytecode file is successful using the preset second class loader, it indicates that the adapted bytecode file is compatible with the JDK version used by the current application, and the target bytecode file only needs to be replaced with the adapted 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. In this case, the bytecode can be located based on the error message, and the characteristic value can be reversed for calibration before attempting version adaptation again.

[0077] By adopting the solution of the present invention, the bytecode files in the jar dependency file can be adapted to the JDK version, so that when these version-adapted bytecode files are loaded, they can be better compatible with the currently running JDK version.

[0078] Example 3

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

[0080] The program type determination module 301 is used 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;

[0081] The dependency file acquisition module 302 is configured to acquire the jar dependency file to be adapted from the dependency library directory of the current application in response to the type of the current application being a web application;

[0082] The bytecode file screening module 303 is used to unpack the jar dependency files to be adapted and select the target bytecode files related to class loading from the unpacked bytecode files;

[0083] The method insertion module 304 is used to determine the calling position of the target bytecode file in the search class method of the first class loader, and insert a preset version adaptation method after the calling position;

[0084] The adaptation module 305 is used to adapt the target bytecode file according to the version adaptation method to obtain an adapted bytecode file;

[0085] The replacement module 306 is used to replace the target bytecode file with the adapted bytecode file.

[0086] In some embodiments, in adapting the target bytecode file according to the version adaptation method to obtain the adapted bytecode file, the adaptation module 305 includes:

[0087] A loading unit, configured to preload a target bytecode file through a preset second class loader;

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

[0089] A comparison unit is used to determine the version distance and adaptation direction based on the JDK version used when compiling the target bytecode file and the JDK version used by the virtual machine running the current application;

[0090] A decision tree acquisition unit is used to acquire a corresponding version decision tree based on the version distance and adaptation direction. The version decision tree is pre-built and stored, including feature differences between different JDK versions.

[0091] The adaptation unit is used to adapt the target bytecode file based on the version decision tree to obtain an adapted bytecode file.

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

[0093] Perform feature matching on 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 an adaptation code based on 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] Merge the method source code and the adaptation code to obtain the method adaptation code;

[0097] The method adaptation code is converted into method adaptation bytecode, and the method bytecode in the target bytecode file is adapted and replaced by the method adaptation bytecode to obtain an adapted bytecode file.

[0098] In some embodiments, replacing the target bytecode file with the adapted bytecode file includes:

[0099] Preload the adapted bytecode file through the preset second class loader;

[0100] If the preloading is successful, the target bytecode file is replaced with the adapted bytecode file.

[0101] In some embodiments, further comprising:

[0102] The adaptation judgment module is used to determine that the target bytecode file does not need to be adapted in response to no error in the loading process of the target bytecode file.

[0103] In some embodiments, a decision tree building module is further included for:

[0104] Create a folder named after the JDK version number in the resource directory of the current application;

[0105] A version decision tree is constructed in the folder. The root node of the version decision tree is the JDK version number. The second-level node is the difference information between the root node JDK version and other JDK versions. The third-level node includes the specific feature values ​​that differ between different JDK versions, the feature value classification, and the prompt words defined under the feature value classification for large model search.

[0106] In some embodiments, in selecting a target bytecode file related to class loading from the bytecode files obtained through the unpacking process, 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 specified characters or the bytecode file inherits from a specified class, then the bytecode file is used as the target bytecode file; wherein the specified characters are classloader and the specified class is the ClassLoader class.

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

[0109] Example 4

[0110] Figure 4 A schematic diagram of an electronic device 10 that can be used to implement an embodiment of the present invention is shown. 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 assistants, cellular phones, smartphones, 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 merely examples and are not intended to limit the implementation of the present invention described and / or claimed herein.

[0111] like Figure 4As shown, electronic device 10 includes at least one processor 11 and memory, such as read-only memory (ROM) 12 and random access memory (RAM) 13, communicatively connected to at least one processor 11. The memory stores computer programs executable by the at least one processor. Processor 11 can perform various appropriate actions and processes based on the computer programs stored in ROM 12 or loaded from storage unit 18 into RAM 13. RAM 13 can also store various programs and data required for the operation of electronic device 10. Processor 11, ROM 12, and RAM 13 are interconnected via bus 14. An input / output (I / O) interface 15 is also connected to 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 magnetic disk, an optical disk, 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 via a computer network such as the Internet and / or various telecommunication networks.

[0113] Processor 11 can be any general-purpose and / or specialized processing component with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various specialized artificial intelligence (AI) computing chips, various processors that run machine learning model algorithms, a digital signal processor (DSP), and any other suitable processor, controller, microcontroller, etc. 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 may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the version adaptation method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the version adaptation method in any other appropriate manner (e.g., by means of firmware).

[0115] Various embodiments of the systems and techniques described above can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), system-on-chip systems (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 interpreted on a programmable system that includes at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0116] Computer programs for implementing the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable version-adapted device, such that when the computer program is executed by the processor, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The computer program may be executed entirely on the machine, partially on the machine, as a stand-alone software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0117] In the context of the present invention, a computer-readable storage medium may be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, device, or apparatus. A computer-readable storage medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or apparatus, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media may include an electrical connection based on 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 of the foregoing.

[0118] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device that has: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the electronic device. Other types 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 that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), a blockchain network, and the Internet.

[0120] A computing system may include clients and servers. The clients and servers are typically remote from each other and typically interact via a communication network. This client-server relationship arises through computer programs running on the respective computers, creating a client-server relationship. The server may be a cloud server, also known as a cloud computing server or cloud host. This server is a hosting product within the cloud computing service ecosystem that addresses the management difficulties and limited scalability of traditional physical hosting and VPS services.

[0121] It should be understood that the various forms of the processes shown above can be used to reorder, add, or delete steps. For example, the steps described in the present invention can be performed 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. This is not limited herein.

[0122] The above specific embodiments do not limit the scope of protection of the present invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions may be made based on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention are intended to be included within the scope of protection of the present invention.

Claims

1. A version adaptation method, characterized in that: include: Loading a 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 current application being a web application, obtaining a jar dependency file to be adapted from a dependency library directory of the current application; wherein, if the compiled version of the bytecode file included in any jar dependency file in the dependency library directory is inconsistent with the JDK version running the current application, then the jar dependency file is the jar dependency file to be adapted; the compiled version refers to the JDK version running when the bytecode file is compiled; Unpacking the jar dependency file to be adapted, and selecting the target bytecode file related to class loading from the bytecode file obtained by the unpacking; In the search class method of the first class loader, a calling position for calling the target bytecode file is determined, and a preset bytecode for adapting the target bytecode file is inserted after the calling position; Adapting the target bytecode file according to the inserted bytecode to obtain an adapted bytecode file; wherein the adapted bytecode file is compatible with the JDK version running the current application; The target bytecode file is replaced by the adapted bytecode file.

2. The method according to claim 1, characterized in that The step of adapting the target bytecode file according to the inserted bytecode to obtain an adapted bytecode file comprises: Preloading the target bytecode file through a preset second class loader; In response to an error in the loading process of the target bytecode file, extracting from the target bytecode file a JDK version used when compiling the target bytecode file; Determining the version distance and adaptation direction based on 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-built and stored, including feature differences between different JDK versions; Based on the version decision tree, the target bytecode file is adapted to obtain an adapted bytecode file.

3. The method according to claim 2, characterized in that The step of adapting the target bytecode file based on the version decision tree to obtain an adapted bytecode file includes: Performing feature matching on 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 an adaptation code according to the version feature value; 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; Merging the method source code with the adaptation code to obtain a method adaptation code; The method adaptation code is converted into a method adaptation bytecode, and the method bytecode in the target bytecode file is adapted and replaced by the method adaptation bytecode to obtain the adapted bytecode file.

4. The method according to claim 3, characterized in that 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, the target bytecode file is replaced with the adapted bytecode file.

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

6. The method according to claim 3, characterized in that Also includes: Create a folder named after the JDK version number in the resource directory of the current application; A version decision tree is constructed in the folder; wherein the root node of the version decision tree is the JDK version number, the second-level node is the difference information between the root node JDK version and other JDK versions, and the third-level node includes specific feature values ​​that differ between different JDK versions, feature value classification, and prompt words defined under the feature value classification for large model search.

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

8. A version adaptation device, characterized in that: include: A program type determination module, configured to load a startup class of a current application program through a preset first class loader, and determine the type of the current application program in the startup class; a dependency file acquisition module, configured to, in response to the current application being a web application, acquire a jar dependency file to be adapted from a dependency library directory of the current application; wherein, if the compiled version of the bytecode file included in any jar dependency file in the dependency library directory is inconsistent with the JDK version running the current application, then the jar dependency file is the jar dependency file to be adapted; the compiled version refers to the JDK version running when the bytecode file is compiled; A bytecode file screening module is used to unpack the jar dependency file to be adapted and select the target bytecode file related to class loading from the bytecode file obtained by the unpacking process; a method insertion module for determining, in the search class method of the first class loader, a call location for calling the target bytecode file, and inserting a preset bytecode for adapting the target bytecode file after the call location; An adaptation module, configured to adapt the target bytecode file according to the inserted bytecode to obtain an adapted bytecode file; wherein the adapted bytecode file is compatible with the JDK version running the current application; A replacement module is used to replace the target bytecode file with the adapted bytecode file.

9. An electronic device, characterized in that: include: at least one processor; as well as a memory communicatively connected to the at least one processor; wherein, The memory stores a computer program executable by the at least one processor. The computer program is executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1 to 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 enable a processor to implement the method according to any one of claims 1 to 7 when executed.

Images