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.
FIG. 1 is a schematic diagram of the main steps of a method of cross programming language interface translation according to an embodiment of the present invention.
As shown in fig. 1, a method for converting across programming language interfaces according to an embodiment of the present invention mainly includes the following steps:
step S101: and generating an IDL file according to the source language interface description class.
In order to increase controllability and flexibility of a cross-programming language interface conversion process, an Interface Definition Language (IDL) file mechanism is introduced, and an IDL file is generated according to an interface description class of a source language in the cross-programming language interface conversion process.
Because the same interface description classes of different programming languages have structural similarity, interface conversion of different programming languages can be realized through the intermediate file IDL file. In the embodiment of the present invention, the step may be performed by obtaining class definition information or interface function definition information of a source language interface description class; and generating IDL file according to the class definition information or the interface function definition information.
It should be noted that, the class definition information or the interface function definition information may be obtained by using reflection characteristics or text parsing, where the class definition information may be information such as a name, an object, an attribute, a method, a type of a field, and a name of a field of an interface class; the interface function definition information may be information such as an interface function name, a function parameter type, a function parameter name, a function return type, and the like, and when the IDL file is generated, class definition information or interface function definition information is acquired from an interface description class of a source language, and the IDL file is generated based on the acquired class definition information or interface function definition information.
Step S102: and editing the IDL file.
To avoid generating excessive redundant code when converting across programming language interfaces and to reduce repetitive work in the modification process. In the embodiment of the present invention, the IDL file generated in step S101 may be edited, that is, the IDL file is maintained. Through editing the IDL file, the modification of the service side interface description class can be synchronized to the interface description class of the calling side, namely if the service side modifies the code, all the modification of the code can be realized only by modifying corresponding contents in the IDL file.
In an embodiment of the present invention, editing the IDL file includes at least one of the following: adding the content of the IDL file; deleting the content of the IDL file; modifying the content of the IDL file; annotations are added to the IDL file.
When the IDL file is edited, the class definition information of the interface description classes such as the class name and the field name can be selected and modified according to actual requirements, and redundant class definition information and interface function definition information can be deleted. The repeated modification work of a large number of redundant codes in the interface conversion process can be reduced by adding, deleting or modifying codes in the IDL file, such as deleting repeated objects in the IDL file. Meanwhile, editing the IDL file may also add extension information of the interface description class by adding a comment, where the comment is used to identify an extension attribute, for example, the comment "@ Member" may be used to identify extra information of the class, the comment "@ Field" may be used to identify extra information of the Field, and the like.
It should be noted that a certain field in the object of interface communication only describes the information of the parent class in the interface description class of the source language, but the actual communication may be a child class and may be an unfixed child class, so that polymorphic information of the field may be manually added to the field in the form of annotation to identify various types of child class information that may exist in the field, for example, the child class is identified by the annotation "@ MutiType".
In embodiments of the invention, the annotation comprises a comment, an extension field or a version number. Wherein comments may be used to identify the meaning of the field, such as comment information for attributes and comment information for methods; the version number can be used for identifying the modification time of the object, namely the interface version is controlled through an IDL file; the extension field, although not involved in the communication between the service party and the caller, may be flexibly used by the caller, such as identifying class definitions, field definitions or version information, etc.
Step S103: and generating a target language interface description class based on the edited IDL file.
The IDL file edited in step S102 may generate an interface description class of a corresponding target language as needed, thereby completing the cross-programming-language interface conversion.
In the embodiment of the present invention, the step may be performed by acquiring class definition information, interface function definition information, comments, version numbers or extension fields in the edited IDL file; and generating the target language interface description class implementation based on the static template technology. In this step, the class definition information, the interface function definition information, or the information added to the IDL file of the interface description class may be obtained from the edited IDL file by using the reflection characteristic or the text parsing, and the corresponding interface description class of the target language is generated based on the static template technique by using the class definition information, the interface function definition information, or the information added to the IDL file.
It is noted that static template technology (freemaker) is a general tool for generating output text (hypertext markup language HTML web pages, emails, configuration files, source code, etc.) based on templates and data to be changed. In addition, the obtained interface description class of the target language can reserve comment information and extension fields added according to version numbers so as to be flexibly used by a caller, such as identification class definition, field definition or version information and the like.
According to the method for converting the cross-programming language interface, the IDL file mechanism technical means is adopted, and the IDL file of the interface definition language is generated according to the source language interface description class; editing the IDL file; and generating a target language interface description class based on the edited IDL file. The technical problems of code redundancy, incapability of self-defining modification, lack of version control and polymorphism are solved by editing the IDL file, so that excessive redundant codes are prevented from being generated during cross-programming language interface conversion; the repeated work in the modification process is reduced; synchronous modification of the service side interface file and the calling side interface file can be realized only by maintaining the IDL intermediate file, so that the controllability and the flexibility of the cross-programming language interface conversion process are improved; the multi-state problem of different programming languages in the code conversion process is effectively solved.
FIG. 2 is a first schematic diagram of interface translation of a method of cross-programming language interface translation according to an embodiment of the present invention.
As shown in fig. 2, in the embodiment of the present invention, a method for converting an interface of a JAVA language to an interface of a C + + language is described as an example, where a service party provides an interface description class of the JAVA language by using the JAVA language; and the calling party uses the C + + language, and finally the interface description class of the C + + language is required to be obtained.
Assuming that two basic attributes and methods of a commodity are provided in an interface description class of JAVA language, class definition information of the interface description class, i.e. information such as name, object, attribute, method, type of field, name of field, etc. of the interface class is acquired before generating an IDL file, the class definition information can be acquired by using reflection characteristics for JAVA language, and the IDL file is generated based on the above information.
Editing the generated IDL file, deleting redundant interfaces and objects, modifying objects and the like or adding annotations, wherein the content of the annotations comprises annotations for identifying field meanings, version numbers for identifying object modification time, extension fields for identifying class definitions or field definitions or version information and the like.
Specifically, in the embodiment of the present invention, annotations "@ Member" and "@ Field" are added, where a Field "desc" of the annotation "@ Member" indicates class annotation information, a Field "cplussnamespace" indicates a C + + namespace, and a Field "rawjsonnnformat" indicates whether to generate an object marker (json) method; the comment "@ Field" indicates Field comment information, the Field "defaultValue" indicates a default value, the Field "jsonnfield" indicates a json method is generated, the Field "extfieldc" indicates a text box, and the Field "version" indicates a version number.
And generating an interface description class of the C + + language based on the edited IDL file. Specifically, the IDL file generated based on the interface description class in the JAVA language may also obtain class definition information and information such as comments, version numbers, extension fields, and the like added to the IDL file by using the reflection characteristic, and the caller generates the interface description class in the C + + language by using the information, and further serializes an object in the interface description class, where the serializing is a process of converting state information of the object into a form that can be stored or transmitted.
FIG. 3 is a second schematic diagram of interface conversion for a method of converting across programming language interfaces, according to an embodiment of the invention.
As shown in fig. 3, the method for converting an interface across programming languages is also described by taking an example of converting an interface in the JAVA language to an interface in the C + + language, where a service party uses the JAVA language to provide interface description classes in the JAVA language; and the calling party uses the C + + language, and finally the interface description class of the C + + language is required to be obtained.
And acquiring interface function definition information in an interface description class of the JAVA language by utilizing reflection characteristics or text analysis, wherein the interface function definition information can be information such as an interface function name, a function parameter type, a function parameter name, a function return type and the like, and generating an IDL file according to the interface function definition information.
Editing the generated IDL file, deleting redundant interfaces and objects, modifying objects and the like or adding annotations, wherein the content of the annotations comprises annotations for identifying field meanings, version numbers for identifying object modification time, extension fields for identifying class definitions or field definitions or version information and the like.
Specifically, annotations "@ Member" and "@ Field" are added in the embodiment of the present invention, where a Field "desc" of the annotation "@ Member" represents class annotation information, a Field "cplussnamespace" represents a C + + namespace, and a Field "rawjsonnnformat" represents whether a json method is generated; the comment "@ Field" desc "indicates Field comment information, the Field" defaultValue "indicates a default value, the Field" jsonnfield "indicates json method generation, the Field" version "indicates a version number, and the Field" MutiType "indicates subclass information in which the actual object of the Field exists.
In addition, there is a polymorphic situation for the object instance in the interface description class in the source language, that is, the object instance in the interface description class in the source language is a parent class, but may actually be a subclass of the parent class, when the interface in the C + + language needs to extend the parent class of the JAVA interface into multiple subclasses, that is, the parent class "BaseProduct" of the JAVA interface is extended into two subclasses, "YushouProduct" and "GlobalProduct", only one annotation field needs to be added to the IDL file, for example, the subclass is identified by the field "mutittype".
After the IDL file is edited, the reflection characteristic or the text analysis tool of the programming language is used to obtain the interface function definition information and the information such as the comments, version numbers and extension fields added in the IDL file, and the IDL file is used to generate the interface description class of the C + + language, when the interface of the C + + language is generated, the subclass type of the interface of the JAVA language is distinguished according to the comment field, for example, when the object in the IDL file is the subclass "com.
FIG. 4 is a schematic diagram of the main modules of an apparatus for cross programming language interface translation according to an embodiment of the present invention.
As shown in FIG. 4, anapparatus 400 for cross-programming language interface translation according to an embodiment of the present invention comprises: afirst generation module 401, anediting module 402 and asecond generation module 403.
Wherein,
afirst generating module 401, configured to generate an IDL file according to a source language interface description class;
anediting module 402, configured to edit the IDL file;
asecond generating module 403, configured to generate a target language interface description class based on the edited IDL file.
In this embodiment of the present invention, thefirst generating module 401 is further configured to: obtaining class definition information or interface function definition information of the source language interface description class; and generating the IDL file according to the class definition information or the interface function definition information.
In an embodiment of the present invention, theediting module 402 is further configured to at least one of: adding the content of the IDL file; deleting the content of the IDL file; modifying the content of the IDL file; adding annotations in the IDL file.
Further, the annotation includes a comment, an extension field, or a version number.
In this embodiment of the present invention, thesecond generating module 403 is further configured to: acquiring the class definition information, the interface function definition information or the annotation in the edited IDL file; and generating a target language interface description class based on a static template technology.
According to the device for converting the cross-programming language interface, disclosed by the embodiment of the invention, the IDL file mechanism technical means is adopted, and the IDL file of the interface definition language is generated according to the source language interface description class; editing the IDL file; and generating a target language interface description class based on the edited IDL file. The technical problems of code redundancy, incapability of self-defining modification, lack of version control and polymorphism are solved by editing the IDL file, so that excessive redundant codes are prevented from being generated during cross-programming language interface conversion; the repeated work in the modification process is reduced; synchronous modification of the server side interface file and the calling side interface file can be realized only by maintaining the IDL intermediate file, so that the controllability and the flexibility of the cross-programming language interface conversion process are improved; the multi-state problem of different programming languages in the code conversion process is effectively solved.
FIG. 5 illustrates anexemplary system architecture 500 of a method of cross programming language interface translation or an apparatus for cross programming language interface translation to which embodiments of the present invention may be applied.
As shown in fig. 5, thesystem architecture 500 may includeterminal devices 501, 502, 503, anetwork 504, and aserver 505. Thenetwork 504 serves to provide a medium for communication links between theterminal devices 501, 502, 503 and theserver 505.Network 504 may include various connection types, such as wired, wireless communication links, or fiber optic cables, to name a few.
The user may use theterminal devices 501, 502, 503 to interact with aserver 505 over anetwork 504 to receive or send messages or the like. Theterminal devices 501, 502, 503 may have various communication client applications installed thereon, such as a shopping application, a web browser application, a search application, an instant messaging tool, a mailbox client, social platform software, and the like.
Theterminal devices 501, 502, 503 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop portable computers, desktop computers, and the like.
Theserver 505 may be a server that provides various services, such as a background management server that supports shopping websites browsed by users using theterminal devices 501, 502, 503. The backend management server may analyze and perform other processing on the received data such as the product information query request, and feed back a processing result (for example, target push information, product information — just an example) to the terminal device.
It should be noted that the method for converting across programming language interfaces provided by the embodiment of the present invention is generally executed by theserver 505, and accordingly, the apparatus for converting across programming language interfaces is generally disposed in theserver 505.
It should be understood that the number of terminal devices, networks, and servers in fig. 5 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.
Referring now to FIG. 6, a block diagram of acomputer system 600 suitable for use with a terminal device implementing an embodiment of the invention is shown. The terminal device shown in fig. 6 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present invention.
As shown in fig. 6, thecomputer system 600 includes a Central Processing Unit (CPU)601 that can perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM)602 or a program loaded from astorage section 608 into a Random Access Memory (RAM) 603. In theRAM 603, various programs and data necessary for the operation of thesystem 600 are also stored. TheCPU 601,ROM 602, andRAM 603 are connected to each other via abus 604. An input/output (I/O)interface 605 is also connected tobus 604.
The following components are connected to the I/O interface 605: aninput portion 606 including a keyboard, a mouse, and the like; anoutput portion 607 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker; astorage section 608 including a hard disk and the like; and acommunication section 609 including a network interface card such as a LAN card, a modem, or the like. Thecommunication section 609 performs communication processing via a network such as the internet. Thedriver 610 is also connected to the I/O interface 605 as needed. Aremovable medium 611 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on thedrive 610 as necessary, so that a computer program read out therefrom is mounted in thestorage section 608 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 may be downloaded and installed from a network through thecommunication section 609, and/or installed from theremovable medium 611. The computer program performs the above-described functions defined in the system of the present invention when executed by the Central Processing Unit (CPU) 601.
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 first generation module, an editing module, and a second generation module. The names of these modules do not in some cases constitute a definition of the module itself, for example, an editing module may also be described as a "module that edits the IDL file".
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 comprise: step S101: generating an IDL file according to the source language interface description class; step S102: editing the IDL file; step S103: and generating a target language interface description class based on the edited IDL file.
According to the technical scheme of the embodiment of the invention, because an IDL file mechanism technical means is adopted, an IDL file of the interface definition language is generated according to the source language interface description class; editing the IDL file; and generating a target language interface description class based on the edited IDL file. The technical problems of code redundancy, incapability of self-defining modification, lack of version control and polymorphism are solved by editing the IDL file, so that excessive redundant codes are prevented from being generated during cross-programming language interface conversion; the repeated work in the modification process is reduced; the synchronous modification of the interface file of the server side and the target code files of the calling side can be realized only by maintaining the IDL intermediate file, so that the controllability and the flexibility of the cross-programming language interface conversion process are improved; the multi-state problem of different program languages in the code conversion process is effectively solved.
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.