CN109901826B - Data processing method and device for Java program and electronic equipment - Google Patents
Data processing method and device for Java program and electronic equipment Download PDFInfo
- Publication number
- CN109901826B CN109901826B CN201910157059.4A CN201910157059A CN109901826B CN 109901826 B CN109901826 B CN 109901826B CN 201910157059 A CN201910157059 A CN 201910157059A CN 109901826 B CN109901826 B CN 109901826B
- Authority
- CN
- China
- Prior art keywords
- program
- java
- interface
- external
- data processing
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Abstract
A data processing method, device and electronic equipment for Java programs are disclosed. The method comprises the following steps: running a Java program on a Java-oriented dynamic model system; accessing a Java local interface by a Java program through a Java-oriented dynamic model system to call a management program, wherein the Java local interface calls the management program to provide a local data request function; calling an application program interface library for an external program by a Java local interface calling management program through a Java local interface; and communicating, by the application program interface library, with an external program running on the external system through the bus mechanism to call the external program to be loaded by the Java native interface call hypervisor, the external program executing the business logic function and returning the result data in response to the call of the application program interface library. Therefore, the application program interface layer and the service logic layer of the Java program can be decoupled, so that the development efficiency of the program is improved, and the maintenance cost is reduced.
Description
Technical Field
The present application relates to the field of data processing technology, and more particularly, to a data processing method and apparatus for a Java program, and an electronic device.
Background
The Java language has very powerful functions and is suitable for developing desktop software, but has disadvantages compared with other languages.
For example, C language is faster and more efficient to execute than java language. Moreover, the C language is more biased to the bottom layer due to the tool of having pointers, and is generally used for hardware-related driver development, which is not done by Java language.
In some cases, it may be desirable for a Java program to be able to call the business logic functions of an external program in another language, which requires data transfer between the Java program and the external program.
However, currently, the Java program directly calls the service logic application program interface in the local dynamic library through the Java native interface, and it cannot well implement data transmission with the external program, so that the service logic function of the external program cannot be applied.
Accordingly, it is desirable to provide an improved data processing scheme for Java programs.
Disclosure of Invention
The present application is proposed to solve the above-mentioned technical problems. Embodiments of the present application provide a data processing method and apparatus for a Java program, and an electronic device, which are capable of calling an application program interface library for an external program to further communicate with the external program through a bus mechanism so as to call a service logic function of the external program, so that an application program interface layer and a service logic layer of the Java program can be decoupled, thereby improving the development efficiency of the program and reducing the maintenance cost.
According to an aspect of the present application, there is provided a data processing method for a Java program, comprising: running a Java program on a dynamic model system facing Java; accessing a Java local interface by the Java program through the Java-oriented dynamic model system to call a management program, wherein the Java local interface calls the management program to provide a local data request function; calling an application program interface library for an external program by the Java local interface calling management program through the Java local interface; and communicating, by the application program interface library, with the external program running on an external system through a bus mechanism to call the external program to be loaded by the Java native interface call hypervisor, the external program executing a business logic function and returning result data in response to the call of the application program interface library.
In the above data processing method for a Java program, the external program is a C/C + + program, and the application program interface is an external program interface library for C language.
In the above data processing method for a Java program, the external system is a Linux system.
In the above-described data processing method for a Java program, the bus mechanism is a DBus mechanism.
In the above data processing method for a Java program, the Java programs running on the Java-oriented dynamic model system communicate with each other through a service mechanism of the Java-oriented dynamic model system framework.
In the above data processing method for a Java program, the Java program and the Java native interface call manager communicate with each other through a service mechanism of the Java-oriented dynamic model system framework.
In the above data processing method for a Java program, the Java-oriented dynamic model system framework runs on a Java virtual machine.
In the above data processing method for a Java program, the bus mechanism is built in the application program interface library to call a service logic function provided by the external program.
In the above data processing method for a Java program, the external program provides attributes and methods for the business logic function under different paths and interfaces, and the bus mechanism obtains the result data by a gateway service program calling and methods corresponding to its corresponding paths and interfaces.
In the above data processing method for a Java program, the method further comprises: and calling a management program by the Java program through the Java local interface and the Java local interface to obtain the result data.
According to another aspect of the present application, there is provided a data processing apparatus for a Java program, comprising: a program running unit for running the Java program on the Java-oriented dynamic model system; the local access unit is used for accessing a Java local interface calling management program by the Java program through the Java-oriented dynamic model system, and the Java local interface calling management program is used for providing a local data request function; the local calling unit is used for calling the management program by the Java local interface to call an application program interface library for an external program through the Java local interface; and the external calling unit is used for communicating with the external program running on an external system through a bus mechanism by the application program interface library so as to call the external program to be loaded by the Java local interface calling management program, and the external program responds to the calling of the application program interface library to execute a service logic function and return result data.
In the above data processing apparatus for Java programs, the external program is a C/C + + program, and the application program interface is an external program interface library for C language.
In the above data processing apparatus for a Java program, the external system is a Linux system.
In the above-described data processing apparatus for a Java program, the bus mechanism is a DBus mechanism.
In the above data processing apparatus for Java programs, communication between the Java programs running on the Java-oriented dynamic model system is performed through a service mechanism of the Java-oriented dynamic model system framework.
In the above data processing apparatus for a Java program, the Java program and the Java native interface call manager communicate with each other through a service mechanism of the Java-oriented dynamic model system framework.
In the above data processing apparatus for a Java program, the Java-oriented dynamic model system framework runs on a Java virtual machine.
In the data processing apparatus for Java programs described above, the bus mechanism is built in the application program interface library to call a service logic function provided by the external program.
In the data processing apparatus for a Java program described above, the external program provides attributes and methods for the business logic function under different paths and interfaces, and the bus mechanism obtains the result data by a gateway service program calling and methods corresponding to its corresponding paths and interfaces.
In the above data processing apparatus for a Java program, further comprising: and the result acquisition unit is used for acquiring the result data by the Java program through the Java local interface and the Java local interface calling management program.
According to still another aspect of the present application, there is provided an electronic apparatus including: a processor; and a memory in which computer program instructions are stored, which, when executed by the processor, cause the processor to perform the data processing method for a Java program as described above.
According to yet another aspect of the present application, there is provided a computer readable medium having stored thereon computer program instructions which, when executed by a processor, cause the processor to execute the data processing method for a Java program as described above.
Compared with the prior art, the data processing method, the data processing device and the electronic equipment for the Java program can call the service logic function of the external program by calling the application program interface library for the external program so as to further communicate with the external program through a bus mechanism. Therefore, the data processing method, the data processing device and the electronic equipment for the Java program can decouple an application program interface layer and a business logic layer of the Java program, so that the development efficiency of the program is improved, and the maintenance cost is reduced.
Drawings
The above and other objects, features and advantages of the present application will become more apparent by describing in more detail embodiments of the present application with reference to the attached drawings. The accompanying drawings are included to provide a further understanding of the embodiments of the application and are incorporated in and constitute a part of this specification, illustrate embodiments of the application and together with the description serve to explain the principles of the application. In the drawings, like reference numbers generally represent like parts or steps.
Fig. 1 is a schematic diagram illustrating an application environment of a data processing method for a Java program according to an embodiment of the present application.
Fig. 2 illustrates a flowchart of a data processing method for a Java program according to an embodiment of the present application.
Fig. 3 is a schematic diagram illustrating an example of a DBus mechanism in a data processing method of a Java program according to an embodiment of the present application.
Fig. 4 illustrates a block diagram of a data processing apparatus for a Java program according to an embodiment of the present application.
FIG. 5 illustrates a block diagram of an electronic device in accordance with an embodiment of the present application.
Detailed Description
Hereinafter, example embodiments according to the present application will be described in detail with reference to the accompanying drawings. It should be understood that the described embodiments are only some embodiments of the present application and not all embodiments of the present application, and that the present application is not limited by the example embodiments described herein.
Summary of the application
As described above, currently, a Java Program directly calls a service logic Application Program Interface (API) in a local dynamic library through a Java local Interface (JNI) to complete tasks such as data request and acquisition, parameter configuration, and status query. That is, the service logic layer and the JNIAPI layer are hybridized together.
Therefore, once the service logic function changes, the JNIPIAI layer and the related modules in the Java program need to be changed; the JNIAPI layer cannot be unified and standardized for different service logic functions, external API development is also required during service logic development, development efficiency is low, and maintenance cost is high. Moreover, the coupling of the JNIAPI layer and the service logic layer is inherently contrary to the software design principle.
Therefore, in view of the above technical problems, the basic concept of the present application is that a Java native interface calls an external program by calling an application program interface library for the external program through a Java native interface, and then the application program interface library communicates with the external program through a bus mechanism, so as to call the external program that is originally to be directly loaded by the Java native interface call manager.
Specifically, the data processing method, device and electronic device for the Java program provided by the present application run the Java program on a Java-oriented dynamic model system first, then the Java program accesses a Java local interface through the Java-oriented dynamic model system to call a hypervisor, the Java local interface calls the hypervisor to provide a local data request function, then the Java local interface calls the hypervisor to call an application interface library for an external program through a Java local interface, and finally the application interface library communicates with the external program running on an external system through a bus mechanism to call the external program to be loaded by the Java local interface call hypervisor, wherein the external program performs a service logic function in response to the call of the application interface library and returns result data.
Thus, the JNIPAPI layer and the service logic layer can be independently and efficiently developed due to the fact that the JNIPAPI layer and the service logic layer are decoupled.
Moreover, a unified and normative JNIPAPI layer can be provided for different service logic requirements, and even if the service logic requirements change, only the internal implementation of an application program interface library needs to be modified, the Java program and the JNIPAPI layer do not need to be modified, and the maintenance cost is reduced.
In addition, because the business logic layer is positioned on an external system, not as a part of a local dynamic library, but as an independently operable program, the multi-party cooperative development is flexible and convenient, and the development efficiency is improved
Having described the general principles of the present application, various non-limiting embodiments of the present application will now be described with reference to the accompanying drawings.
Overview of the System
Fig. 1 is a schematic diagram illustrating an application environment of a data processing method for a Java program according to an embodiment of the present application.
As shown in fig. 1, a plurality of Java programs, such as Java program 1, Java program 2, and the like, run on the Java-oriented dynamic model system (OSGi). Here, OSGi can be considered as a module layer of the Java platform, and the OSGi framework provides a common container for Java systems in which bundles (bundles) can be installed, uninstalled, and updated without stopping the system. Therefore, the OSGi specification has a very perfect mechanism for physical isolation of modules, module interaction and multi-version aspects. And, as further shown in FIG. 1, OSGi runs on top of a Java Virtual Machine (JVM).
When the Java program needs to call the service, the Java program firstly accesses the basic service program, and if the basic service program cannot provide the service needed by the Java program, the JNI call management program is further accessed, and the service is called by the JNI call management program through the JNI. Here, JNI provides several APIs to implement communication in Java and other languages (e.g., C + +, etc.). Therefore, in the embodiment of the present application, the external program may be in C language, C + + language, or other languages. Also, the external program runs on an external system, for example, the external system may be a Linux system or other systems.
Starting from Java1.1, the JNI standard becomes part of the Java platform, which allows Java code to interact with code written in other languages. In addition, JNI enables interaction between Java programs and hardware and operating systems, and can improve program performance.
In the embodiment of the present application, instead of directly loading an external program through JNI by the JNI call manager, the JNI call manager calls an application program interface library for the external program through JNI, for example, if the external program is in C language, the application program interface library may be referred to as a CAPI library. And, the application program interface library further communicates with an external program running on an external system through a bus mechanism, such as a DBus mechanism, to call the external program.
Here, the DBus mechanism is a relatively advanced inter-process communication technology by which one-to-one and many-to-many peer-to-peer communication between processes is possible. Specifically, when a process sends a message to another process, the message is sent to the DBus daemon process, and then the DBus daemon process forwards the message to a destination process. That is, the DBus daemon plays the role of a transfer station. It is noted that the main concept of the DBus mechanism is a bus, through which processes connected to the bus can accept or pass messages, and that the bus, upon receipt of a message, performs different processing according to different message types. Therefore, in the embodiments of the present application, the bus mechanism is not limited to the DBus mechanism.
And finally, the external program responds to the calling of the application program interface library to execute a service logic function and returns result data, so that the decoupling of the JNIPAPI layer and the service logic layer is realized.
Hereinafter, the data processing method for a Java program according to the embodiment of the present application will be described in further detail.
Exemplary method
Fig. 2 illustrates a flowchart of a data processing method for a Java program according to an embodiment of the present application.
As shown in fig. 2, a data processing method for a Java program according to an embodiment of the present application includes: s110, running a Java program on a Java-oriented dynamic model system; s120, accessing a Java local interface calling management program by the Java program through the Java-oriented dynamic model system, wherein the Java local interface calling management program is used for providing a local data request function; s130, calling an application program interface library for an external program by the Java local interface calling management program through the Java local interface; and S140, communicating with the external program running on the external system through a bus mechanism by the application program interface library to call the external program to be loaded by the Java native interface call management program, wherein the external program responds to the call of the application program interface library to execute a service logic function and return result data.
In step S110, a Java program is run on the Java-oriented dynamic model system. Here, the Java program runs under a Java-oriented dynamic model system, i.e., an OGSi framework, and communicates therebetween through a service mechanism of an OSGi framework. Also, as described above, the OSGi framework runs on top of the JVM, as a module layer of the Java platform, supporting dynamic installation, uninstallation, and upgrade of updates of plug-ins within the framework without rebooting the platform.
In step S120, accessing, by the Java program through the Java-oriented dynamic model system, a Java native interface call manager, where the Java native interface call manager is used to provide a native data request function. Here, if the Java program is to obtain data, it needs to communicate with the JNI call manager through a service mechanism provided by the OSGi framework, call the JNI method to perform data request, data acquisition, parameter configuration, status query, and the like.
In step S130, an application program interface library for an external program is called by the Java native interface call manager through the Java native interface. That is, in the embodiment of the present application, the JNI call manager calls the application program interface library method through the JNI mechanism to implement data request, data acquisition, parameter configuration, status query, and the like.
In step S140, the application program interface library communicates with the external program running on the external system through a bus mechanism. As described above, in the case where the external program is C/C + + language, the application program interface library is a CAPI library, which is a C/C + + dynamic library to be loaded by Java, which provides a unified and standardized API for JNI invocation externally and invokes a business logic method provided by the external program through a DBus mechanism inside thereof.
Therefore, in the data processing method for the Java program according to the embodiment of the present application, the bus mechanism is built in the application program interface library to call the service logic function provided by the external program.
In the embodiment of the application, an external program running on an external system, for example, a C/C + + program running on Linux, implements a business logic function, and in response to a call initiated by a CAPI library from a DBus, executes a business logic operation and returns execution result data.
Therefore, the external program is an independent program running in an external system environment, the internal part of the external program realizes specific business logic functions, and the external part responds to remote calling from an application program interface library through a DBus mechanism, executes calling actions and returns executed result data.
For example, the CAPI library communicates with a C/C + + program running on Linux, which is connected to the DBus bus as a recipient of the DBus and provides attributes and methods under different paths and interfaces to satisfy business logic functions, through the DBus mechanism. And the CAPI library is connected with the DBus bus as a DBus requester, and the DBuS bus informs the gateway service program to call the method under the path and the interface corresponding to the DBuS bus to acquire data and state.
Therefore, in the data processing method for the Java program according to the embodiment of the present application, the external program provides the attributes and methods for the business logic function under different paths and interfaces, and the bus mechanism acquires the result data by a gateway service program call and a method corresponding to its corresponding path and interface.
And finally, the Java program acquires returned result data through the JNI layer and the JNI calling management program.
That is, in the data processing method for a Java program according to an embodiment of the present application, further comprising: and calling a management program by the Java program through the Java local interface and the Java local interface to obtain the result data.
In another example, in the data processing method for a Java program according to an embodiment of the present application, the JNI call manager may register a service through a registerService () method of a BundleContext provided by an OSGi framework, and another Java program may acquire a service registered by the JNI call manager through a getServiceReference () and getService () method of the BundleContext. Through the service, the Java program can call the method provided by the JNI call management program to realize data request, data acquisition, parameter configuration, state query and the like.
Concrete application example
Fig. 3 is a schematic diagram illustrating an example of a DBus mechanism in a data processing method of a Java program according to an embodiment of the present application. As shown in FIG. 3, the DBus mechanism may be implemented as a DBus daemon including an internal connection to a CAPI library and an external connection to a Linux program. Through the internal connection, the CAPI library calls a service logic function or establishes a signal and waits for a result, and through the external connection, the Linux program realizes the service logic function or sends the signal and returns the result.
In this example, the DBus mechanism according to the embodiment of the present application provides a well-defined communication mechanism between a Java program based on DBus and a Linux C/C + + program, which can be divided into the following parts:
And 1, calling a JNI library written by C/C + + by a Java program through JNI as an upper layer part of the whole communication mechanism.
2. The whole upper layer part is only an empty shell and does not relate to the realization of functional requirements, and the Java program only calls the API in the JNI library according to the functional requirements.
The JNI library encapsulates an API meeting Java function requirements to supply Java layer calls, but the JNI library does not specifically realize the required functions, but encapsulates another API in a C/C + + CAPI library.
And 4, taking the CAPI library and the Linux C/C + + program as the bottom part of the communication mechanism, and mainly taking charge of completing the function requirements.
The CAPI library encapsulates a large number of APIs to obtain the data and state of the underlying Linux C/C + + program, but the APIs in the CAPI library are not simple interfaces for calling Linux C/C + +.
And 6, carrying out interprocess communication between the API of the CAPI library and the Linux C/C + + of the bottom layer through the DBus so as to realize data interaction. As shown in FIG. 3, the API and Linux C/C + + in the CAPI library are connected to the DBus to generate an internal connection and an external connection, respectively, and the internal connection and the external connection are the unique identifiers of the two processes in the DBus daemon process.
The Linux C/C + + program as a server creates a large number of objects and binds paths and interfaces to this object as its identification. And the object also has a virtual function table, which is actually a function array (function interface for realizing function requirement).
8. The paths, interfaces and methods in the virtual function table of the objects are negotiated by a CAPI library and a Linux C/C + + program. After the Linux C/C + + package is completed, the CAPI can implement the corresponding functional requirements through its internal connections and paths, interfaces and methods of all objects.
And 9, connecting the API interface in the CAPI and the Linux C/C + + program by the same DBus bus, and calling a method of the Linux C/C + + program of the receiver through different paths and interfaces to acquire data or complete corresponding functions according to different API functions.
And 10, after calling the method in the Linux C/C + +, the API in the CAPI waits for a result to be returned, and the CAPI library can acquire corresponding data according to the result or judge whether the function is executed successfully.
It can be seen that the communication mechanism of the Java program based on the DBus and the Linux C/C + + program is well-defined, the whole upper layer part is responsible for interaction with the outside and the bottom layer part, and the bottom layer part is responsible for completing the corresponding functional requirements and returning the results to the upper layer to be provided to the Java side.
And the lower layer part of the communication mechanism of the Java program based on the DBus and the Linux C/C + + program is in charge of interacting with the upper layer part by a CAPI library, and then calls the Linux C/C + + program through the DBus to complete corresponding functions and return results to the JNI library.
The CAPI library not only plays a role of a transfer hub for connecting an upper layer and a Linux C/C + +, but also is a key of a communication mechanism of a Java program and a Linux C/C + + program based on DBus, and the CAPI library perfectly solves the defects of high coupling degree, low development efficiency and the like caused by directly calling the LINUX C/C + + library by the JNI library. Moreover, the DBus and the Linux C/C + + program are interacted, so that the whole communication mechanism is more hierarchical, low in coupling degree and high in development efficiency.
Exemplary devices
Fig. 4 illustrates a block diagram of a data processing apparatus for a Java program according to an embodiment of the present application.
As shown in fig. 4, a data processing apparatus 200 for a Java program according to an embodiment of the present application includes: a program running unit 210 for running a Java program on the Java-oriented dynamic model system; a local access unit 220, configured to access, by the Java program through the Java-oriented dynamic model system, a Java local interface call manager, where the Java local interface call manager is configured to provide a local data request function; a local calling unit 230, configured to call, by the Java native interface call manager, an application program interface library for an external program through the Java native interface; and an external calling unit 240, configured to communicate, by the application program interface library, with the external program running on an external system through a bus mechanism, to call the external program to be loaded by the Java native interface call hypervisor, where the external program performs a business logic function and returns result data in response to the call of the application program interface library.
In one example, in the data processing apparatus 200 for Java programs described above, the external program is a C/C + + program, and the application program interface is an external program interface library for C language.
In one example, in the above-described data processing apparatus 200 for a Java program, the external system is a Linux system.
In one example, in the above-described data processing apparatus 200 for a Java program, the bus mechanism is a DBus mechanism.
In one example, in the data processing apparatus 200 for Java programs described above, communication between the Java programs running on the Java-oriented dynamic model system is via a service mechanism of the Java-oriented dynamic model system framework.
In one example, in the data processing apparatus 200 for a Java program described above, the Java program and the Java native interface call manager communicate with each other through a service mechanism of the Java-oriented dynamic model system framework.
In one example, in the data processing apparatus 200 for a Java program described above, the Java-oriented dynamic model system framework runs on a Java virtual machine.
In one example, in the data processing apparatus 200 for a Java program described above, the bus mechanism is built in the application program interface library to call a service logic function provided by the external program.
In one example, in the data processing apparatus 200 for a Java program described above, the external program provides attributes and methods for the business logic function under different paths and interfaces, and the bus mechanism acquires the result data by a gateway service program calling and a method corresponding to its corresponding path and interface.
In one example, in the data processing apparatus 200 for a Java program described above, further comprising: and the result acquisition unit is used for acquiring the result data by the Java program through the Java local interface and the Java local interface calling management program.
Here, it will be understood by those skilled in the art that the specific functions and operations of the respective units and modules in the data processing apparatus 200 for a Java program described above have been described in detail in the above description of the data processing method for a Java program with reference to fig. 2, and thus, a repetitive description thereof will be omitted.
As described above, the data processing apparatus 200 for Java programs according to the embodiment of the present application can be implemented in various terminal devices. Such as a server or a terminal running Java programs, such as a smart phone, desktop computer, notebook computer, etc. In one example, the data processing apparatus 200 for a Java program according to an embodiment of the present application may be integrated into a terminal device as one software module and/or hardware module. For example, the data processing apparatus 200 for a Java program may be a software module in the operating system of the terminal device, or may be an application developed for the terminal device; of course, the data processing apparatus 200 for Java programs may also be one of many hardware modules of the terminal device.
Alternatively, in another example, the data processing apparatus for Java program 200 and the terminal device may be separate devices, and the data processing apparatus for Java program 200 may be connected to the terminal device through a wired and/or wireless network and transmit the interactive information according to an agreed data format.
Exemplary electronic device
Next, an electronic apparatus according to an embodiment of the present application is described with reference to fig. 5.
FIG. 5 illustrates a block diagram of an electronic device in accordance with an embodiment of the present application.
As shown in fig. 5, the electronic device 10 includes one or more processors 11 and memory 12.
The processor 13 may be a Central Processing Unit (CPU) or other form of processing unit having data processing capabilities and/or instruction execution capabilities, and may control other components in the electronic device 10 to perform desired functions.
In one example, the electronic device 10 may further include: an input device 13 and an output device 14, which are interconnected by a bus system and/or other form of connection mechanism (not shown).
The input device 13 may include, for example, a keyboard, a mouse, and the like.
The output device 14 can output various information including result data returned by an external program to the outside. The output devices 14 may include, for example, a display, speakers, a printer, and a communication network and its connected remote output devices, among others.
Of course, for simplicity, only some of the components of the electronic device 10 relevant to the present application are shown in fig. 5, and components such as buses, input/output interfaces, and the like are omitted. In addition, the electronic device 10 may include any other suitable components depending on the particular application.
Exemplary computer program product and computer-readable storage Medium
In addition to the above-described methods and apparatuses, embodiments of the present application may also be a computer program product comprising computer program instructions that, when executed by a processor, cause the processor to perform the steps in the data processing method for a Java program according to various embodiments of the present application described in the above-mentioned "exemplary methods" section of this specification.
The computer program product may be written with program code for performing the operations of embodiments of the present application in any combination of one or more programming languages, including an object oriented programming language such as Java, C + + or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computing device, partly on the user's device, as a stand-alone software package, partly on the user's computing device and partly on a remote computing device, or entirely on the remote computing device or server.
Furthermore, embodiments of the present application may also be a computer readable storage medium having stored thereon computer program instructions, which, when executed by a processor, cause the processor to perform the steps in the data processing method for a Java program according to various embodiments of the present application described in the "exemplary methods" section of this specification, above.
The computer-readable storage medium may take any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may include, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples (a non-exhaustive list) of the readable storage medium include: an electrical connection having one or more wires, a portable 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 disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
The foregoing describes the general principles of the present application in conjunction with specific embodiments, however, it is noted that the advantages, effects, etc. mentioned in the present application are merely examples and are not limiting, and they should not be considered essential to the various embodiments of the present application. Furthermore, the foregoing disclosure of specific details is provided for purposes of illustration and understanding only, and is not intended to limit the application to the details which are set forth in order to provide a thorough understanding of the present application.
The block diagrams of devices, apparatuses, systems referred to in this application are only given as illustrative examples and are not intended to require or imply that the connections, arrangements, configurations, etc. must be made in the manner shown in the block diagrams. These devices, apparatuses, devices, systems may be connected, arranged, configured in any manner, as will be appreciated by one skilled in the art. Words such as "including," "comprising," "having," and the like are open-ended words that mean "including, but not limited to," and are used interchangeably therewith. The words "or" and "as used herein mean, and are used interchangeably with, the word" and/or, "unless the context clearly dictates otherwise. The word "such as" is used herein to mean, and is used interchangeably with, the phrase "such as but not limited to".
It should also be noted that in the devices, apparatuses, and methods of the present application, each component or step can be decomposed and/or re-combined. These decompositions and/or recombinations should be considered as equivalents of the present application.
The previous description of the disclosed aspects is provided to enable any person skilled in the art to make or use the present application. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects without departing from the scope of the application. Thus, the present application is not intended to be limited to the aspects shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
The foregoing description has been presented for purposes of illustration and description. Furthermore, the description is not intended to limit embodiments of the application to the form disclosed herein. While a number of example aspects and embodiments have been discussed above, those of skill in the art will recognize certain variations, modifications, alterations, additions and sub-combinations thereof.
Claims (9)
1. A data processing method for a Java program, comprising:
running a Java program on a Java-oriented dynamic model system;
Accessing a Java local interface by the Java program through the Java-oriented dynamic model system to call a management program, wherein the Java local interface calls the management program to provide a local data request function;
calling an application program interface library for an external program by the Java local interface calling management program through the Java local interface; and
communicating, by the application program interface library through a bus mechanism, with the external program running on an external system to invoke the external program to be loaded by the Java native interface call hypervisor, the external program executing a business logic function and returning result data in response to the invocation of the application program interface library;
wherein, the external program is a C/C + + program, and the application program interface library is an external program interface library for C language; the external system is a Linux system; the bus mechanism is a DBus mechanism;
the communication mechanism between the DBus-based Java program and the Linux C/C + + program provided by the DBus mechanism comprises the following parts:
calling a Java local interface library compiled by C/C + + by a Java program through a Java local interface to serve as an upper layer part of the whole communication mechanism;
the whole upper layer part does not relate to the realization of the function requirement, and the Java program calls an API in a Java local interface library according to the function requirement;
The Java local interface library packages an API meeting Java function requirements for calling a Java layer, and packages an API in another C/C + + application program interface library;
the application program interface library and the Linux C/C + + program at the bottom layer are used as the bottom layer part of the communication mechanism and are responsible for completing the function requirements;
an API packaged by an application program interface library acquires data and states of a bottom-layer Linux C/C + + program;
the API in the application program interface library and the Linux C/C + + in the bottom layer are communicated among the processes through the DBus, so that data interaction is realized, the API in the application program interface library and the Linux C/C + + in the DBus are connected to generate internal connection and external connection respectively, and the internal connection and the external connection are unique identifiers of the two processes in the DBus daemon process;
the Linux C/C + + program as a server creates a plurality of objects, binds paths and interfaces for the objects as identifiers of the objects, and the objects also have a virtual function table;
the method in the path, interface and virtual function table of the object is that the application program interface library and the Linux C/C + + program are negotiated, after the Linux C/C + + package is completed, the application program interface library can realize the corresponding function requirement through the internal connection and the path, interface and method of all the objects;
API interfaces in the application program interface library and Linux C/C + + programs are connected through the same DBus bus, and then according to the difference of each API function, a method for calling the Linux C/C + + program of a receiver through different paths and interfaces is used for acquiring data or completing corresponding functions;
and after calling the method in the Linux C/C + +, the API in the application program interface library waits for a return result, and the application program interface library can acquire corresponding data according to the return result or judge whether the function is successfully executed.
2. A data processing method for a Java program as claimed in claim 1, wherein communication between the Java programs running on the Java-oriented dynamic model system is via a service mechanism of the Java-oriented dynamic model system framework.
3. A data processing method for a Java program as claimed in claim 2, wherein the Java program communicates with the Java native interface call manager through a service mechanism of the Java-oriented dynamic model system framework.
4. A data processing method for a Java program according to claim 2 or 3, wherein the Java-oriented dynamic model system framework runs on a Java virtual machine.
5. The data processing method for a Java program according to claim 1, wherein,
the bus mechanism is built in the application program interface library to call the service logic function provided by the external program.
6. The data processing method for a Java program according to claim 1, wherein,
the external program provides attributes and methods for the business logic functions under different paths and interfaces, and
and the bus mechanism acquires the result data by calling the method corresponding to the path and the interface corresponding to the gateway service program through the gateway service program.
7. The data processing method for a Java program according to claim 1, further comprising:
and calling a management program by the Java program through the Java local interface and the Java local interface to obtain the result data.
8. A data processing apparatus for a Java program to implement the data processing method for a Java program according to any one of claims 1 to 7, comprising:
a program running unit for running the Java program on the Java-oriented dynamic model system;
the local access unit is used for accessing a Java local interface calling management program by the Java program through the Java-oriented dynamic model system, and the Java local interface calling management program is used for providing a local data request function;
The local calling unit is used for calling the management program by the Java local interface to call an application program interface library for an external program through the Java local interface; and
an external calling unit, configured to communicate, by the application program interface library, with the external program running on an external system through a bus mechanism, to call the external program to be loaded by the Java local interface call hypervisor;
and the external program responds to the calling of the application program interface library to execute a service logic function and return result data.
9. An electronic device, comprising:
a processor; and
memory in which computer program instructions are stored, which computer program instructions, when executed by the processor, cause the processor to carry out the data processing method for a Java program as claimed in any of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910157059.4A CN109901826B (en) | 2019-03-01 | 2019-03-01 | Data processing method and device for Java program and electronic equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910157059.4A CN109901826B (en) | 2019-03-01 | 2019-03-01 | Data processing method and device for Java program and electronic equipment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109901826A CN109901826A (en) | 2019-06-18 |
| CN109901826B true CN109901826B (en) | 2022-06-10 |
Family
ID=66946107
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910157059.4A Active CN109901826B (en) | 2019-03-01 | 2019-03-01 | Data processing method and device for Java program and electronic equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109901826B (en) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20120126920A (en) * | 2011-05-13 | 2012-11-21 | (주)쉬프트웍스 | Method for Anti-Encoding Android by Using Java Native Interface |
| CN103019748A (en) * | 2013-01-15 | 2013-04-03 | 珠海金山办公软件有限公司 | Method and system for embedding local application program into desktop window in Linux |
| CN103746959A (en) * | 2013-11-27 | 2014-04-23 | 上海斐讯数据通信技术有限公司 | Java and C communication mechanism implementation method in OSGi environment |
| CN107239350A (en) * | 2016-03-28 | 2017-10-10 | 中国电信股份有限公司 | Method and system for calling gateway capacity |
-
2019
- 2019-03-01 CN CN201910157059.4A patent/CN109901826B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20120126920A (en) * | 2011-05-13 | 2012-11-21 | (주)쉬프트웍스 | Method for Anti-Encoding Android by Using Java Native Interface |
| CN103019748A (en) * | 2013-01-15 | 2013-04-03 | 珠海金山办公软件有限公司 | Method and system for embedding local application program into desktop window in Linux |
| CN103746959A (en) * | 2013-11-27 | 2014-04-23 | 上海斐讯数据通信技术有限公司 | Java and C communication mechanism implementation method in OSGi environment |
| CN107239350A (en) * | 2016-03-28 | 2017-10-10 | 中国电信股份有限公司 | Method and system for calling gateway capacity |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109901826A (en) | 2019-06-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11829787B2 (en) | Multi-process model for cross-platform applications | |
| US10862982B2 (en) | Cloud-scale heterogeneous datacenter management infrastructure | |
| JP5496683B2 (en) | Customization method and computer system | |
| US10019298B2 (en) | Middleware interface and middleware interface generator | |
| US20060200802A1 (en) | Systems, methods and architecture for facilitating software access to acceleration technology | |
| US11860796B2 (en) | Execution space agnostic device drivers | |
| CN113971095A (en) | KUBERNETES application program interface in extended process | |
| US20200167713A1 (en) | Business processing method, apparatus, device and system using the same, and readable storage medium of the same | |
| EP2941696A1 (en) | Software interface for a hardware device | |
| CN112256414A (en) | Method and system for connecting multiple computing storage engines | |
| US20120227057A1 (en) | Driver Shimming | |
| CN110659104B (en) | Service monitoring method and related equipment | |
| EP3633507B1 (en) | Technologies for secure and efficient native code invocation for firmware services | |
| WO2014107542A1 (en) | Capability based device driver framework | |
| CN109901826B (en) | Data processing method and device for Java program and electronic equipment | |
| CN109445960B (en) | Application routing method, device and storage medium | |
| CN114564241B (en) | Method and device for accessing hardware device, computer device and storage medium | |
| CN115562887A (en) | Inter-core data communication method, system, device and medium based on data package | |
| WO2021129853A1 (en) | Mobile service upgrade method and apparatus, and terminal | |
| CN115701077A (en) | Method and device for docking micro-service grids | |
| CN106843851A (en) | Implementation method and device based on ActiveMQ isomery Classloader unserializings | |
| CN108804236B (en) | AIDL file sharing method and system | |
| US10402454B1 (en) | Obtaining platform-specific information in a firmware execution environment | |
| CN117170738B (en) | Method, system, equipment and storage medium for interaction of Python and Fortran | |
| CN113596958B (en) | Terminal equipment data interaction method, system, equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |