CN111045746A

CN111045746A - Code expansion method and framework

Info

Publication number: CN111045746A
Application number: CN201811187869.6A
Authority: CN
Inventors: 胡博
Original assignee: Beijing Jingdong Century Trading Co Ltd; Beijing Jingdong Shangke Information Technology Co Ltd
Current assignee: Beijing Jingdong Century Trading Co Ltd; Beijing Jingdong Shangke Information Technology Co Ltd
Priority date: 2018-10-12
Filing date: 2018-10-12
Publication date: 2020-04-21

Abstract

The invention discloses a code expansion method and a code expansion framework, and relates to the technical field of computers. Wherein, the method comprises the following steps: when a virtual machine loads a byte code file, judging whether the byte code file is registered; under the condition that the byte code file is registered, inquiring a corresponding plug-in object from a registry; and modifying the byte code file according to the plug-in object, and returning the modified byte code file to the virtual machine. Through the steps, not only can the code class of the project be expanded, but also the code jar package provided by a third party can be expanded. In addition, by providing a unified code extension method or framework, the development complexity of developers can be simplified, and the development efficiency can be improved.

Description

Code expansion method and framework

Technical Field

The present invention relates to the field of computer technologies, and in particular, to a code extension method and a code extension framework.

Background

In the JAVA development process, if other non-service function extensions (e.g. logging, transaction, security audit, etc.) need to be performed on the class that has been developed, the method generally uses Spring AOP or JAVA dynamic proxy.

In the process of implementing the invention, the inventor finds that at least the following problems exist in the prior art: the Spring AOP or JAVA dynamic agent can only carry out code expansion on the code class of the project, but cannot carry out code expansion on the code provided by a third party.

Disclosure of Invention

In view of the above, the present invention provides a code extension method and framework, which can not only extend the code class of the project itself, but also extend the code provided by the third party. In addition, by providing a unified code extension method or framework, the development complexity of developers can be simplified, and the development efficiency can be improved.

To achieve the above object, according to one aspect of the present invention, a code spreading method is provided.

The code spreading method of the present invention includes: when a virtual machine loads a byte code file, judging whether the byte code file is registered; under the condition that the byte code file is registered, inquiring a corresponding plug-in object from a registry; and modifying the byte code file according to the plug-in object, and returning the modified byte code file to the virtual machine.

Optionally, the method further comprises: loading and packaging the specified plug-in to obtain a plug-in object result set; the plug-in object result set comprises at least one plug-in object; and registering the plug-in object result set to obtain the registry.

Optionally, the method further comprises: before the step of loading and packaging the specified plug-in to obtain a plug-in object result set is executed, filtering the read plug-in according to a white list or a black list, and taking the filtered plug-in as the specified plug-in; the filtered insert comprises: and the byte code file name carried by the plug-in is on the white list, or the byte code file name carried by the plug-in is not on the black list.

Optionally, the registry is a HashMap, including: and Key Value pairs with the name of the byte code file as a Key Value and the name of the plug-in object as a Value.

Optionally, the required virtual machine is a Java virtual machine, and the method is implemented based on an Agent mechanism of the Java virtual machine.

To achieve the above object, according to another aspect of the present invention, a code extension framework is provided.

The code extension framework of the present invention comprises: the judging module is used for judging whether the byte code file is registered or not when the virtual machine loads the byte code file; the query module is used for querying a corresponding plug-in object from a registry under the condition that the byte code file is registered; and the modification module is used for modifying the byte code file according to the plug-in object and returning the modified byte code file to the virtual machine.

Optionally, the frame further comprises: the assembly module is used for loading and packaging the specified plug-in to obtain a plug-in object result set; the plug-in object result set comprises at least one plug-in object; and the registration module is used for registering the plug-in object result set to obtain the registry.

Optionally, the assembly module is further configured to, before performing the operation of loading and packaging the specified plug-in to obtain a plug-in object result set, filter the read plug-in according to a white list or a black list, and use the filtered plug-in as the specified plug-in; the filtered insert comprises: and the byte code file name carried by the plug-in is on the white list, or the byte code file name carried by the plug-in is not on the black list.

Optionally, the required virtual machine is a Java virtual machine, and the framework is implemented based on an Agent mechanism of the Java virtual machine.

To achieve the above object, according to still another aspect of the present invention, there is provided an electronic apparatus.

The electronic device of the present invention includes: one or more processors; and storage means for storing one or more programs; when the one or more programs are executed by the one or more processors, the one or more processors are caused to implement the code extension method of the present invention.

To achieve the above object, according to still another aspect of the present invention, there is provided a computer-readable medium.

The computer-readable medium of the present invention has stored thereon a computer program which, when executed by a processor, implements the code extension method of the present invention.

One embodiment of the above invention has the following advantages or benefits: judging whether a byte code file is registered or not when the byte code file is loaded in a virtual machine; under the condition that the byte code file is registered, inquiring a corresponding plug-in object from a registry; and modifying the byte code file according to the plug-in object, so that not only can the code class of the project be expanded, but also the codes provided by a third party can be expanded. In addition, by providing a unified code extension method or framework, the development complexity of developers can be simplified, and the development efficiency can be improved.

Further effects of the above-mentioned non-conventional alternatives will be described below in connection with the embodiments.

Drawings

The drawings are included to provide a better understanding of the invention and are not to be construed as unduly limiting the invention. Wherein:

fig. 1 is a schematic diagram of the main steps of a code spreading method according to a first embodiment of the present invention;

fig. 2 is a schematic diagram of the main steps of a code spreading method according to a second embodiment of the present invention;

FIG. 3 is a schematic diagram of the main modules of a code expansion framework according to a third embodiment of the present invention;

FIG. 4 is a schematic diagram of the main modules of a code expansion framework according to a fourth embodiment of the present invention;

FIG. 5 is an exemplary system architecture diagram in which embodiments of the present invention may be employed;

FIG. 6 is a diagram illustrating the architecture of plug-in objects in an embodiment of the present invention;

FIG. 7 is a block diagram of a computer system suitable for use with the electronic device to implement an embodiment of the invention.

Detailed Description

Exemplary embodiments of the present invention are described below with reference to the accompanying drawings, in which various details of embodiments of the invention are included to assist understanding, and which are to be considered as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the invention. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.

It should be noted that the embodiments and features of the embodiments may be combined with each other without conflict.

Before describing embodiments of the present invention in detail, some technical terms related to the present invention will be described.

Spring AOP: AOP was implemented in Spring framework. AOP, an abbreviation of Aspect Programming, means "cut plane-Oriented Programming", and can implement a technique for dynamically and uniformly adding functions to a program without modifying source codes through a pre-compiling mode and a runtime dynamic agent.

JVM: a Java virtual machine.

HashMap: is a data structure, which may be understood as a table structure for storing key-value pairs.

The Premain method comprises the following steps: JVM exposes an interface entry method for user extension.

Class file: all known as Java class files, make Java more suitable for networks, mainly in terms of platform independence and network mobility. Its tasks in terms of platform independence are: a Java program is provided with binary-form services that are independent of the underlying host platform.

ClassFileTransformer interface: a class extension interface provided by JVM.

ClassFileTransformer object: instantiation of implementation classes of the ClassFileTransformer interface.

Fig. 1 is a schematic diagram of the main steps of a code spreading method according to a first embodiment of the present invention. As shown in fig. 1, the code spreading method according to the embodiment of the present invention includes:

step S101, when the virtual machine loads the byte code file, judging whether the byte code file is registered.

Illustratively, the virtual machine is a JVM (Java virtual machine), and the bytecode file is a Class file. In this example, the file name of the Class file loaded by the JVM may be compared to the Class file name on the registry. If the file name of the Class file loaded by the JVM exists in the registry, the Class file loaded by the JVM is considered to be registered; and if the file name of the Class file loaded by the JVM is not in the registry, the Class file loaded by the JVM is considered to be unregistered.

And step S102, under the condition that the byte code file is registered, inquiring a corresponding plug-in object from a registry.

Illustratively, the registry may be a HashMap, and may include: and Key Value pairs with the name of the byte code file as a Key Value and the name of the plug-in object as a Value. In this example, HashMap may be queried according to the filename of the bytecode file loaded by the virtual machine to query out the corresponding plug-in object. The plug-in object can understand an instantiation object after loading and packaging the plug-in, and a byte code file modification engine is packaged in the plug-in object. Wherein the plug-in is mainly used for providing extension codes; the plug-in object is primarily used to provide logic for adding extension code to a bytecode file.

And S103, modifying the byte code file according to the plug-in object, and returning the modified byte code file to the virtual machine.

In the embodiment of the invention, the non-intrusive type expansion of the codes can be realized through the steps, so that not only can the code class of the project be expanded, but also the code jar package provided by a third party can be expanded. In addition, by providing a unified code extension method or framework, developers only need to pay attention to developing extension logic and do not need to pay attention to how to add the extension logic into the code, development complexity of the developers is simplified, and development efficiency is improved.

Fig. 2 is a schematic diagram of the main steps of a code spreading method according to a second embodiment of the present invention. As shown in fig. 2, the code spreading method according to the embodiment of the present invention includes:

step S201, reading the plug-in under the appointed directory, and filtering the plug-in according to a white list or a black list.

In an alternative embodiment, a white list of bytecode files may be preset, and the bytecode file name carried by the plug-in may be compared with the bytecode file name on the white list. If the byte code file name carried by the plug-in is on the white list, the plug-in is reserved, namely, the plug-in is used as the remaining plug-in for filtering; and if the byte code file name carried by the plug-in is not on the white list, filtering the plug-in.

In another alternative embodiment, a black list of bytecode files may be preset, and the bytecode file name carried by the plug-in may be compared with the bytecode file name on the black list. If the byte code file name carried by the plug-in is not on the blacklist, the plug-in is reserved, namely, the plug-in is used as the remaining plug-in for filtering; and if the byte code file name carried by the plug-in is on the blacklist, filtering the plug-in.

In the embodiment of the invention, by filtering the plug-in according to the white list or the black list, some important byte code files can be protected to prevent the important byte code files from being modified by a user.

And S202, loading and packaging the filtered plug-ins to obtain a plug-in object result set. The plug-in object result set comprises at least one plug-in object, and each plug-in object carries a byte code file name.

Wherein the remaining inserts of the filter comprise: and the byte code file name carried by the plug-in is on the white list, or the byte code file name carried by the plug-in is not on the black list. The plug-in object can understand an instantiation object after loading and packaging the plug-in, and a byte code file modification engine is packaged in the plug-in object. Wherein the plug-in is mainly used for providing extension codes; the plug-in object is primarily used to provide logic for adding extension code to a bytecode file. Illustratively, when the method of the present invention is implemented based on the JVM agent mechanism, the plug-in object may be a ClassFileTransformer object.

And step S203, registering the plug-in object result set to obtain a registry.

In this step, the plug-in object result set may be traversed, and a Key-Value pair may be constructed with the name of the bytecode file carried by each plug-in object as a Key Value and the name of each plug-in object as a Value, thereby obtaining a registry including the Key-Value pair.

Step S204, when the virtual machine loads the byte code file, judging whether the byte code file is registered.

Illustratively, the virtual machine may be a JVM (Java virtual machine), and the bytecode file is a Class file. In this example, the file name of the Class file loaded by the JVM may be compared to the Class file name on the registry. If the file name of the Class file loaded by the JVM exists in the registry, the Class file loaded by the JVM is considered to be registered; and if the file name of the Class file loaded by the JVM is not in the registry, the Class file loaded by the JVM is considered to be unregistered.

Step S205, in a case where the bytecode file is not registered, ends the flow.

In specific implementation, when the bytecode file is not registered, a prompt message of "Null" may be returned to the JVM, and then the process is ended.

Step S206, under the condition that the byte code file is registered, inquiring a corresponding plug-in object from the registry.

Illustratively, the registry may be a HashMap, and may include: and Key Value pairs with the name of the byte code file as a Key Value and the name of the plug-in object as a Value. In this example, HashMap may be queried according to the filename of the bytecode file loaded by the virtual machine to query out the corresponding plug-in object. By adopting HashMap to store the registration information, the query speed can be improved.

Step S207, modifying the byte code file according to the plug-in object, and returning the modified byte code file to the virtual machine.

Illustratively, when the method of the present invention is implemented based on the JVM Agent mechanism, the plug-in object may be a ClassFileTransformer object. In this example, the Class file loaded by the JVM may be modified according to a ClassFileTransformer object and the modified Class file returned to the JVM.

Fig. 3 is a schematic diagram of main blocks of a code extension framework according to a third embodiment of the present invention. As shown in FIG. 3, a code extension framework 300 of an embodiment of the present invention includes: a judging module 301, a query module 302 and a modification module 303.

The determining module 301 is configured to determine whether a bytecode file is registered when the bytecode file is loaded by the virtual machine.

Illustratively, the virtual machine is a JVM (Java virtual machine), and the bytecode file is a Class file. In this example, the determination module 301 may compare the file name of the Class file loaded by the JVM with the Class file name on the registry. If the file name of the Class file loaded by the JVM exists in the registry, the Class file loaded by the JVM is considered to be registered, and the Class file is considered to need to be extended; if the file name of the Class file loaded by the JVM is not in the registry, the Class file loaded by the JVM is considered to be unregistered, and further the Class file is considered not to need to be extended.

The query module 302 is configured to query a corresponding plug-in object from the registry when the bytecode file is registered.

Illustratively, the registry may be a HashMap, and may include: and Key Value pairs with the name of the byte code file as a Key Value and the name of the plug-in object as a Value. In this example, query module 302 may query HashMap according to the filename of the bytecode file loaded by the virtual machine to query the corresponding plug-in object. The plug-in object can understand an instantiation object after loading and packaging the plug-in, and a byte code file modification engine is packaged in the plug-in object. Wherein the plug-in is mainly used for providing extension codes; the plug-in object is primarily used to provide logic for adding extension code to a bytecode file.

A modifying module 303, configured to modify the bytecode file according to the plug-in object, and return the modified bytecode file to the virtual machine.

In the embodiment of the invention, the non-intrusive type expansion of the codes can be realized through the framework, so that not only can the code class of the project be expanded, but also the code jar package provided by a third party can be expanded. In addition, by providing a unified code extension method or framework, developers only need to pay attention to developing extension logic and do not need to pay attention to how to add the extension logic into the code, development complexity of the developers is simplified, and development efficiency is improved.

Fig. 4 is a schematic diagram of main blocks of a code extension framework according to a fourth embodiment of the present invention. As shown in FIG. 4, a code extension framework 400 of an embodiment of the present invention includes: an assembly module 401, a registration module 402, a judgment module 403, a query module 404, and a modification module 405.

The assembly module 401 is configured to load and package the specified plug-in to obtain a plug-in object result set. The plug-in object result set includes at least one plug-in object. The plug-in object can understand an instantiation object after loading and packaging the plug-in, and a byte code file modification engine is packaged in the plug-in object. Wherein the plug-in is mainly used for providing extension codes; the plug-in object is primarily used to provide logic for adding extension code to a bytecode file. Illustratively, when implementing the framework of the present invention based on the JVM Agent mechanism, the plug-in object may be a ClassFileTransformer object.

In another embodiment, before performing the operation of loading and packaging the specified plug-in to obtain the plug-in object result set, the assembly module 401 may further perform the following operations: the assembly module 401 filters the read plug-ins according to the white list or the black list, and takes the filtered plug-ins as the specified plug-ins. Wherein the filtered insert comprises: and the byte code file name carried by the plug-in is on the white list, or the byte code file name carried by the plug-in is not on the black list. In the embodiment of the invention, by filtering the plug-in according to the white list or the black list, some important byte code files can be protected to prevent the important byte code files from being modified by a user.

A registering module 402, configured to register the plug-in object result set to obtain a registry. For example, the registration module 402 may traverse the plug-in object result set, and construct a Key-Value pair with the name of the bytecode file carried by each plug-in object as a Key Value and the name of each plug-in object as a Value, so as to obtain a registry including the Key-Value pair.

The determining module 403 is configured to determine whether the bytecode file is registered when the bytecode file is loaded by the virtual machine. If the bytecode file is judged to be registered, the query module 404 can be called; and under the condition that the bytecode file is judged to be unregistered, ending the process, namely not modifying the bytecode file.

The query module 404 is configured to query the corresponding plug-in object from the registry if the bytecode file is registered.

Illustratively, the registry may be a HashMap, and may include: and Key Value pairs with the name of the byte code file as a Key Value and the name of the plug-in object as a Value. In this example, the HashMap may be queried according to the filename of the bytecode file loaded by the virtual machine to query the corresponding plug-in object from the HashMap.

A modification module 405, configured to modify the bytecode file according to the plug-in object, and return the modified bytecode file to the virtual machine.

Illustratively, when implementing the framework of the present invention based on the JVM Agent mechanism, the plug-in object may be a ClassFileTransformer object. In this example, the Class file loaded by the JVM may be modified according to a ClassFileTransformer object and the modified Class file returned to the JVM.

Fig. 5 is an exemplary system architecture diagram in which embodiments of the present invention may be employed. As shown in fig. 5, the system architecture of the present invention includes: JVM Agent 501, code extension framework 502.

JVM Agent 501, a mechanism provided by the JVM, may be understood as a collection of interfaces exposed by the JVM for user extension. In an embodiment of the present invention, a code extension method or a code extension framework may be implemented based on an interface provided by the JVM Agent 501 for modifying a class. Based on this mechanism, a plug-in object, specifically a ClassFileTransformer object, can be registered in the JVM.

The code extension framework 502 is a framework which is formed by uniformly abstracting and packaging a bytecode modification part on the basis of a JVM Agent mechanism, and provides a uniform bytecode modification interface. On this basis, the code extension framework 502 also implements the extension mechanism of "kernel + plug-in".

A code extension framework 502 comprising: the device comprises an assembly module, a registration module, a judgment module, an inquiry module and a modification module. At JVM startup, the build module may be started by calling the Premain method. Then, the assembly module can load and package the specified plug-in to obtain a plug-in object result set. The plug-in object result set may then be registered by the registration module to obtain a registry. When the JVM loads a Class file, whether the Class file needs to be extended or not can be judged through the judgment module. And, under the condition that the Class file needs to be extended, modifying the Class file through the query module and the modification module, and returning the modified Class file to the JVM.

FIG. 6 is a diagram illustrating an architecture of a plug-in object according to an embodiment of the present invention. When the code extension method according to the embodiment of the present invention is implemented based on the JVM Agent mechanism, the plug-in object 600 may be a ClassFileTransformer object.

The plug-in object 600 includes context information, which may be denoted as "instrumentation context". In the instrumentation context, information of the bytecode modification engine is mainly included. The plug-in object also includes a bytecode modification engine, which may be denoted as "InstruentEngine". In "instrumentation Engine", an ASM or other bytecode modification tool is packaged. In addition, "InstrumentEngine" includes a Class encapsulation object (which may be denoted as "InstrumentClass") and a Method encapsulation object (which may be denoted as "InstrumentMethod"). Wherein, the 'instrumentation Class' is an encapsulation object for a Class object in Java, and the 'instrumentation Method' is an encapsulation object for a Method object in Java. Additionally, plug-in object 600 also includes an extension point interface (which may be denoted as "Interreceptor"). "Interreceptor" is used to provide the main extension logic. In the embodiment of the invention, the 'interpolator' is realized by a plug-in. When it is confirmed that code extension needs to be performed on the Class file loaded by the JVM, the Class file can be encapsulated by "InstrumentClass" in "InstrumentEngine" and then extended by the addressor method in "InstrumentMethod". After the code is expanded, the modified Class file is returned to the JVM.

FIG. 7 illustrates a schematic structural diagram of a computer system 700 suitable for use with the electronic device to implement an embodiment of the invention. The computer system illustrated in FIG. 7 is only an example and should not impose any limitations on the scope of use or functionality of embodiments of the invention.

As shown in fig. 7, the computer system 700 includes a Central Processing Unit (CPU)701, which can perform various appropriate actions and processes in accordance with a program stored in a Read Only Memory (ROM)702 or a program loaded from a storage section 708 into a Random Access Memory (RAM) 703. In the RAM703, various programs and data necessary for the operation of the system 700 are also stored. The CPU 701, the ROM 702, and the RAM703 are connected to each other via a bus 704. An input/output (I/O) interface 705 is also connected to bus 704.

The following components are connected to the I/O interface 705: an input portion 706 including a keyboard, a mouse, and the like; an output section 707 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker; a storage section 708 including a hard disk and the like; and a communication section 709 including a network interface card such as a LAN card, a modem, or the like. The communication section 709 performs communication processing via a network such as the internet. A drive 710 is also connected to the I/O interface 705 as needed. A removable medium 711 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 710 as necessary, so that a computer program read out therefrom is mounted into the storage section 708 as necessary.

In particular, according to the embodiments of the present disclosure, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated in the flow chart. In such an embodiment, the computer program can be downloaded and installed from a network through the communication section 709, and/or installed from the removable medium 711. The computer program performs the above-described functions defined in the system of the present invention when executed by the Central Processing Unit (CPU) 701.

It should be noted that the computer readable medium shown in the present invention can be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having 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. In the present invention, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present invention, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The modules described in the embodiments of the present invention may be implemented by software or hardware. The described modules may also be provided in a processor, which may be described as: a processor includes a determination module, a query module, and a modification module. The names of these modules do not constitute a limitation to the module itself in some cases, and for example, the determination module may be described as a "module that determines whether a bytecode file is registered.

As another aspect, the present invention also provides a computer-readable medium that may be contained in the apparatus described in the above embodiments; or may be separate and not incorporated into the device. The computer readable medium carries one or more programs which, when executed by a device, cause the device to perform the following: when a virtual machine loads a byte code file, judging whether the byte code file is registered; under the condition that the byte code file is registered, inquiring a corresponding plug-in object from a registry; and modifying the byte code file according to the plug-in object, and returning the modified byte code file to the virtual machine.

The above-described embodiments should not be construed as limiting the scope of the invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions can occur, depending on design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A method of code spreading, the method comprising:

when a virtual machine loads a byte code file, judging whether the byte code file is registered;

under the condition that the byte code file is registered, inquiring a corresponding plug-in object from a registry;

and modifying the byte code file according to the plug-in object, and returning the modified byte code file to the virtual machine.

2. The method of claim 1, further comprising:

loading and packaging the specified plug-in to obtain a plug-in object result set; the plug-in object result set comprises at least one plug-in object; and registering the plug-in object result set to obtain the registry.

3. The method of claim 2, further comprising:

before the step of loading and packaging the specified plug-in to obtain a plug-in object result set is executed, filtering the read plug-in according to a white list or a black list, and taking the filtered plug-in as the specified plug-in; the filtered insert comprises: and the byte code file name carried by the plug-in is on the white list, or the byte code file name carried by the plug-in is not on the black list.

4. The method of claim 1, wherein the registry is a HashMap, comprising: and Key Value pairs with the name of the byte code file as a Key Value and the name of the plug-in object as a Value.

5. The method according to any one of claims 1 to 4, wherein the required virtual machine is a Java virtual machine, and the method is implemented based on an Agent mechanism of the Java virtual machine.

6. A code extension framework, the framework comprising:

the judging module is used for judging whether the byte code file is registered or not when the virtual machine loads the byte code file;

the query module is used for querying a corresponding plug-in object from a registry under the condition that the byte code file is registered;

and the modification module is used for modifying the byte code file according to the plug-in object and returning the modified byte code file to the virtual machine.

7. The frame of claim 6, further comprising:

the assembly module is used for loading and packaging the specified plug-in to obtain a plug-in object result set; the plug-in object result set comprises at least one plug-in object;

and the registration module is used for registering the plug-in object result set to obtain the registry.

8. The framework of claim 7, wherein the assembly module is further configured to, before performing the operation of loading and packaging the specified plug-in to obtain a plug-in object result set, filter the read plug-in according to a white list or a black list, and use the filtered plug-in as the specified plug-in; the filtered insert comprises: and the byte code file name carried by the plug-in is on the white list, or the byte code file name carried by the plug-in is not on the black list.

9. The framework of claim 6, wherein the registry is a HashMap comprising: and Key Value pairs with the name of the byte code file as a Key Value and the name of the plug-in object as a Value.

10. The framework of any one of claims 6 to 9, wherein the required virtual machine is a Java virtual machine, and the framework is implemented based on an Agent mechanism of the Java virtual machine.

11. An electronic device, comprising:

one or more processors;

a storage device for storing one or more programs,

when executed by the one or more processors, cause the one or more processors to implement the method of any one of claims 1-5.

12. A computer-readable medium, on which a computer program is stored, which program, when being executed by a processor, is adapted to carry out the method of any one of claims 1 to 5.