CN110275710A - Method and system for checking consistency of Java local interface, storage medium and terminal - Google Patents

Abstract

The present invention provides a Java local interface consistency checking method and system, a storage medium and a terminal, comprising the following steps: introducing a plug-in for recording JNI parameter information of a function at the compilation stage; Modify the Native library of the Native library so that the JNI parameter information is added in the Native library; when the JVM is running, in the JNI dynamic link process, compare whether the JNI parameter information in the Native is consistent with the JNI parameter information in Java, and When consistent, dynamically link via the JNI. In the Java local interface consistency check method and system, storage medium and terminal of the present invention, the complete information of the symbol in the Native library is checked by the JVM at the Native library link stage, to ensure that the interface in the Java declaration is completely consistent with the implementation in the Native, And in the case of inconsistency, an exception is thrown immediately to avoid unpredictable behavior.

Description

Method and system for checking consistency of Java local interface, storage medium and terminal

technical field

The invention relates to the technical field of IT, in particular to a Java local interface consistency checking method and system, a storage medium and a terminal.

Background technique

The Java Native Interface (JNI) is a programming framework that provides several application programming interfaces (Application Programming Interface, API) to realize the communication between Java and other languages (mainly C&C++). Starting with Java 1.1, the JNI standard has become part of the Java platform, which allows Java code to interact with code written in other languages. JNI was originally designed for native compiled languages, especially C and C++, but does not prevent the use of other programming languages, as long as the calling convention is supported. Using Java to interact with natively compiled code often results in a loss of platform portability. However, there are situations where it is acceptable, or even necessary, to do so. For example, use some old library to interact with hardware, operating system, or to improve the performance of the program. The JNI standard at least guarantees that native code can work in any Java virtual machine environment.

Specifically, a Java program can call a Native program through JNI, and vice versa. Native programs are usually written in C/C++ or assembly language, which makes it possible to develop multiple languages such as Java and C/C++/ASM. In many cases, it is necessary to resort to JNI, for example, if you want to control the hardware at the JAVA level, or use some Native algorithm optimization libraries, or sometimes even need to directly access some services of the underlying operating system.

Specifically, an example of JNI is as follows:

It can be seen from the above that the Native part includes a header file and an implementation file, the Java part includes the declaration of the interface, and the loading and calling of the Native library.

Since the Java code is compiled, packaged or linked separately from the Native code. If there is an inconsistency between the Native interface implementation and the Java declared interface, there is no way to find this problem at the compilation stage.

What's even more frightening is that for the JNI implemented in C language, there is no way to find this problem even during the loading process of the Native library. This can cause unexpected problems during program execution.

There is no effective JNI consistency check scheme in the prior art. The usual practice is to declare the Native method in Java, and then use tools such as Javah to generate the Native code header file. Native references the header file and implements it according to the interface definition, and then lets the Native code compiler identify the interface inconsistency. The above approach can avoid the problem of JNI inconsistency to a certain extent. However, in many cases, developers do not follow this development process, and many developers even develop Native completely manually. Due to coding errors and loose testing, this inconsistent JNI is deployed until undefined behavior occurs at runtime.

Contents of the invention

In view of the above-mentioned shortcoming of the prior art, the object of the present invention is to provide a kind of Java local interface consistency checking method and system, storage medium and terminal, check Native by Java Virtual Machine (Java Virtual Machine, JVM) in Native library link stage The complete information of the symbol in the library ensures that the interface in the Java declaration is completely consistent with the implementation in Native, and in case of inconsistency, an exception is thrown immediately to avoid unpredictable behavior.

In order to achieve the above object and other related objects, the present invention provides a method for checking the consistency of Java local interface, comprising the following steps: introducing a plug-in for recording the JNI parameter information of the function at the compilation stage; The generated Native library is modified to increase the JNI parameter information in the Native library; when the JVM is running, in the JNI dynamic link process, compare whether the JNI parameter information in the Native is consistent with the JNI parameter information in Java, And dynamically link via said JNI when consistent.

In an embodiment of the present invention, when the JNI parameter information in Native is inconsistent with the JNI parameter information in Java, an exception is thrown immediately.

In an embodiment of the present invention, it also includes establishing an index based on the function name to the JNI parameter information, so as to obtain the corresponding JNI parameter information in Native according to the function name during the JNI dynamic linking process.

In an embodiment of the present invention, it also includes adding a segment in the Native library, and recording the JNI parameter information into the segment.

Correspondingly, the present invention provides a Java local interface consistency check system, including an import module, a modification module and a check module;

The import module is used to introduce a plug-in for recording the JNI parameter information of the function during the compilation phase;

The modification module is used to modify the generated Native library by the plug-in during the generation of the Native library, so that the JNI parameter information is added in the Native library;

The inspection module is used for JVM runtime, and compares whether the JNI parameter information in Native is consistent with the JNI parameter information in Java during the JNI dynamic linking process, and passes through the JNI dynamic link when they are consistent.

In an embodiment of the present invention, the detection module is further configured to immediately throw an exception when the JNI parameter information in Native is inconsistent with the JNI parameter information in Java.

In an embodiment of the present invention, the import module is also used to establish an index based on the function name to the JNI parameter information, so as to obtain the corresponding JNI parameter information in Native according to the function name during the JNI dynamic linking process.

In an embodiment of the present invention, the modification module is further configured to add a segment in the Native library, and record the JNI parameter information into the segment.

The present invention provides a storage medium on which a computer program is stored, and when the program is executed by a processor, the above method for checking the consistency of the Java local interface is realized.

Finally, the present invention provides a terminal, including a processor and a memory;

The memory is used to store computer programs;

The processor is configured to execute the computer program stored in the memory, so that the terminal executes the above Java native interface consistency checking method.

As mentioned above, the Java local interface consistency check method and system, storage medium and terminal of the present invention have the following beneficial effects:

(1) In the Native library linking stage, the JVM checks the complete information of the symbol in the Native library to ensure that the interface in the Java declaration is completely consistent with the implementation in Native;

(2) Accurately check the JNI consistency at runtime, and throw an exception immediately when the interface in the Java statement is inconsistent with the implementation in Native, which can completely avoid the program uncertainty caused by JNI inconsistency Behavior.

Description of drawings

Fig. 1 is shown as the flow chart of the Java local interface consistency check method in an embodiment of the present invention;

Fig. 2 shows the structural representation of the Java native interface consistency checking system in an embodiment of the present invention;

FIG. 3 is a schematic structural diagram of a terminal of the present invention in an embodiment.

Component designation description

21 import module

22 Modification module

23 Check module

31 processors

32 memory

Detailed ways

Embodiments of the present invention are described below through specific examples, and those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various modifications or changes can be made to the details in this specification based on different viewpoints and applications without departing from the spirit of the present invention.

The Java local interface consistency check method and system, storage medium and terminal of the present invention check the complete information of the symbol in the Native library by the JVM at the Native library link stage of the Java system, to ensure that the interface in the Java statement is completely consistent with the realization in the Native Consistent, and in the case of inconsistency, an exception is thrown immediately, thereby avoiding unpredictable behavior and ensuring the stability of the system operation.

As shown in Figure 1, in one embodiment, the Java local interface consistency check method of the present invention comprises the following steps:

Step S1, introducing a plug-in for recording the JNI parameter information of the function in the compilation stage.

Specifically, during the JNI linking process, the JVM will first search for the JNI implementation corresponding to the symbol. For C++, its symbol is mangling name, which is generated by the compiler based on the function name and parameter information, which itself already contains parameter information, so it can ensure the consistency of JNI when the symbol search is successful. For the C language, its compiler does not generate mangling names from parameter information. Therefore, the present invention introduces plug-ins in the C compilation stage. The plug-in can record the JNI parameter information of the function, and build an index based on the function name to the JNI parameter information.

Step S2. During the generation of the native library, the plug-in modifies the generated native library, so that the JNI parameter information is added to the native library.

In an embodiment of the present invention, when the generated Native library is modified by the plug-in, a segment is added to the Native library, and the JNI parameter information is recorded in the segment.

Step S3, when the JVM is running, compare whether the JNI parameter information in Native is consistent with the JNI parameter information in Java during the JNI dynamic linking process, and dynamically link through the JNI if they are consistent.

Specifically, in the JNI dynamic linking process, firstly, based on the index of the function name to the JNI parameter information, the JNI parameter information in the corresponding Native is obtained according to the function name in the JNI dynamic linking process; and then the JNI parameter information in the Native is compared with the Java Whether the JNI parameter information in is consistent. Among them, when the two are consistent, they are dynamically linked through JNI; when they are inconsistent, an exception is thrown immediately, thereby avoiding the program's uncertain behavior caused by JNI inconsistency.

As shown in FIG. 2 , in one embodiment, the Java native interface consistency check system of the present invention includes an import module 21 , a modification module 22 and a check module 23 .

The import module 21 is used to import a plug-in that records JNI parameter information of a function during the compilation phase.

Specifically, during the JNI linking process, the JVM will first search for the JNI implementation corresponding to the symbol. For C++, its symbol is a mangling name, which is generated by the compiler based on the function name and parameter information, which itself already contains parameter information, so it can ensure the consistency of JNI when the symbol search is successful. For the C language, its compiler does not generate mangling names from parameter information. Therefore, the present invention introduces plug-ins in the C compilation stage. The plug-in can record the JNI parameter information of the function, and build an index based on the function name to the JNI parameter information.

The modification module 22 is connected with the introduction module 21, and is used for modifying the generated Native library by the plug-in during the generation process of the Native library, so that the JNI parameter information is added to the Native library.

In an embodiment of the present invention, when the generated Native library is modified by the plug-in, a segment is added to the Native library, and the JNI parameter information is recorded in the segment.

The checking module 23 is connected with the modifying module 22, and is used for JNI dynamic linking process when JVM is running, comparing whether the JNI parameter information in Native is consistent with the JNI parameter information in Java, and passing through the JNI dynamic link when consistent.

Specifically, in the JNI dynamic linking process, firstly, based on the index of the function name to the JNI parameter information, the JNI parameter information in the corresponding Native is obtained according to the function name in the JNI dynamic linking process; and then the JNI parameter information in the Native is compared with the Java Whether the JNI parameter information in is consistent. Among them, when the two are consistent, they are dynamically linked through JNI; when they are inconsistent, an exception is thrown immediately, thereby avoiding the program's uncertain behavior caused by JNI inconsistency.

It should be noted that it should be understood that the division of each module of the above device is only a division of logical functions, and may be fully or partially integrated into one physical entity or physically separated during actual implementation. And these modules can all be implemented in the form of calling software through processing components; they can also be realized in the form of hardware; some modules can also be realized in the form of calling software through processing components, and some modules can be realized in the form of hardware. For example, the x module can be a separate processing component, and can also be integrated in a chip of the above-mentioned device. In addition, it can also be stored in the memory of the above-mentioned device in the form of program code, and can be implemented by a certain processing component of the above-mentioned device. Call and execute the function of the above x module. The implementation of other modules is similar. In addition, all or part of these modules can be integrated together, and can also be implemented independently. The processing component described here may be an integrated circuit with signal processing capability. In the implementation process, each step of the above method or each module above can be completed by an integrated logic circuit of hardware in the processor component or an instruction in the form of software.

For example, the above modules may be one or more integrated circuits configured to implement the above method, for example: one or more specific integrated circuits (Application Specific Integrated Circuit, referred to as ASIC), or, one or more microprocessors ( Digital Signal Processor (DSP for short), or one or more Field Programmable Gate Arrays (Field Programmable Gate Array, FPGA for short), etc. For another example, when one of the above modules is implemented in the form of a processing component scheduler code, the processing component may be a general-purpose processor, such as a central processing unit (Central Processing Unit, CPU for short) or other processors that can call program codes. For another example, these modules can be integrated together and implemented in the form of a system-on-a-chip (SOC for short).

The computer program is stored on the storage medium of the present invention, and when the program is executed by the processor, the above-mentioned method for checking the consistency of the Java local interface is realized. The storage medium includes: various media capable of storing program codes such as ROM, RAM, magnetic disk, U disk, memory card or optical disk.

As shown in FIG. 3 , in an embodiment, the terminal of the present invention includes: a processor 31 and a memory 32 .

The memory 32 is used to store computer programs.

The memory 32 includes various media capable of storing program codes such as ROM, RAM, magnetic disk, U disk, memory card or optical disk.

The processor 31 is connected to the memory 32, and is used to execute the computer program stored in the memory 32, so that the terminal executes the above Java native interface consistency checking method.

Preferably, the processor 31 can be a general-purpose processor, including a central processing unit (Central Processing Unit, referred to as CPU), a network processor (Network Processor, referred to as NP), etc.; it can also be a digital signal processor (Digital Signal Processor, DSP for short), Application Specific Integrated Circuit (ASIC for short), Field Programmable Gate Array (Field Programmable Gate Array, FPGA for short) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

In summary, the Java local interface consistency check method and system, storage medium and terminal of the present invention check the complete information of the symbol in the Native library by the JVM at the Native library link stage, to ensure that the interface in the Java statement is consistent with the symbol in the Native The implementation is completely consistent; the JNI consistency is accurately checked at runtime, and when the interface in the Java declaration is inconsistent with the implementation in Native, an exception is thrown immediately, which can completely avoid program uncertainty caused by JNI inconsistency sexual behavior. Therefore, the present invention effectively overcomes various shortcomings in the prior art and has high industrial application value.

The above-mentioned embodiments only illustrate the principles and effects of the present invention, but are not intended to limit the present invention. Anyone skilled in the art can modify or change the above-mentioned embodiments without departing from the spirit and scope of the present invention. Therefore, all equivalent modifications or changes made by those skilled in the art without departing from the spirit and technical ideas disclosed in the present invention should still be covered by the claims of the present invention.

Claims (10)

1. A Java local interface consistency checking method, is characterized in that, comprises the following steps: Introduce a plug-in that records the JNI parameter information of the function during the compilation phase; During the Native library generation process, the generated Native library is modified by the plug-in, so that the JNI parameter information is added in the Native library; When the JVM is running, during the JNI dynamic linking process, compare whether the JNI parameter information in the Native is consistent with the JNI parameter information in the Java, and dynamically link through the JNI when they are consistent. 2. The Java local interface consistency checking method according to claim 1, characterized in that: when the JNI parameter information in Native is inconsistent with the JNI parameter information in Java, an exception is thrown immediately. 3. the Java local interface consistency checking method according to claim 1, is characterized in that: also comprise setting up the index based on function name to JNI parameter information, to obtain the corresponding Native according to function name in JNI dynamic linking process JNI parameter information. 4. The Java native interface consistency checking method according to claim 1, further comprising adding a segment in the Native library, and recording the JNI parameter information into the segment. 5. A Java local interface consistency checking system, is characterized in that, comprises introducing module, revising module and checking module; The import module is used to introduce a plug-in for recording the JNI parameter information of the function during the compilation phase; The modification module is used to modify the generated Native library by the plug-in during the generation of the Native library, so that the JNI parameter information is added in the Native library; The inspection module is used for JVM runtime, and compares whether the JNI parameter information in Native is consistent with the JNI parameter information in Java during the JNI dynamic linking process, and passes through the JNI dynamic link when they are consistent. 6. The Java native interface consistency check method according to claim 5, characterized in that: the detection module is also used for throwing an exception immediately when the JNI parameter information in Native is inconsistent with the JNI parameter information in Java. 7. the Java local interface consistency check method according to claim 5, is characterized in that: described introduction module is also used for setting up the index based on function name to JNI parameter information, to obtain according to function name in JNI dynamic linking process The corresponding JNI parameter information in Native. 8. The Java native interface consistency check method according to claim 5, characterized in that: the modification module is also used to add a segment in the Native library, and record the JNI parameter information into the segment. 9. A storage medium, on which a computer program is stored, characterized in that, when the program is executed by a processor, the Java native interface consistency checking method according to any one of claims 1 to 4 is implemented. 10. A terminal, comprising a processor and a memory; The memory is used to store computer programs; The processor is configured to execute the computer program stored in the memory, so that the terminal executes the Java native interface consistency checking method according to any one of claims 1 to 4.