Method, program product, electronic device and storage medium for invoking native functions by a java card

Abstract

The application provides a method, a program product, an electronic device and a storage medium for JAVA card to call a Native function, the method comprising: accepting a function call request initiated by the JAVA card to a recompiled JAVA operating system based on a pre-defined uniform call interface, the function call request being used to call a target Native function, the recompiled JAVA operating system integrating a bridge file generated according to the uniform call interface, the bridge file being mapped to a Native layer, and the recompiled JAVA operating system pre-linking one or more Native function libraries; in response to the function call request, the recompiled JAVA operating system routes the function call request to a uniform distribution function of the Native layer through bridge mapping, and calls an operation function in the corresponding Native function library to execute the target Native function. An efficient request distribution process is implemented.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a method, program product, electronic device, and storage medium for calling native functions from a JAVA card. Background Technology

[0002] A Java Card is a smart card capable of running Java programs. Compared to traditional smart cards, the main advantages of a Java Card are its support for dynamic downloading of multiple applications and secure isolation. The standard Java Card API focuses on basic encryption algorithms, communication, and memory management, making it difficult to meet the customized functionalities required by some application scenarios. Furthermore, extended functionality is implemented in underlying native code (native libraries), which are developed by third parties, further increasing the difficulty of invoking it. Summary of the Invention

[0003] The purpose of this application is to provide a method, program product, electronic device, and storage medium for calling native functions from a JAVA card, in order to improve the above-mentioned problems.

[0004] In a first aspect, embodiments of this application provide a method for a JAVA card to invoke native functions, comprising: accepting a function call request initiated by the JAVA card to a recompiled JAVA operating system based on a predefined unified call interface, the function call request being used to invoke a target native function, the function call request including a library index and a function identifier; the recompiled JAVA operating system integrating a bridging file generated according to the unified call interface, the bridging file being mapped to the native layer, and the recompiled JAVA operating system pre-linking one or more native function libraries; in response to the function call request, the recompiled JAVA operating system routing the function call request to a unified dispatch function in the native layer through bridging mapping, and the unified dispatch function invoking an operation function in the corresponding native function library according to the library index and the function identifier, and executing the target native function through the operation function.

[0005] In the above implementation process, by defining a fixed and unchanging unified calling interface, the problem of frequent interface changes caused by function expansion or modification is fundamentally reduced, and the coupling between the Java card and native functions is lowered. A two-level routing mechanism based on library indexes and function identifiers, combined with automatically generated bridge mappings, achieves an efficient and automated request distribution process, accurately routing general requests from the Java layer to the corresponding native functions, improving calling efficiency and system automation. It also supports directly pre-linking third-party binary native libraries into the system, allowing different vendors to independently and concurrently develop, test, and upgrade their functional modules without disclosing the source code, effectively protecting the source code of all parties and providing a highly flexible and easily maintainable method for Java cards to call native functions.

[0006] Optionally, in this embodiment of the application, before accepting a function call request initiated by the JAVA card based on a predefined unified call interface to the recompiled JAVA operating system, the method further includes: obtaining a predefined JAVA class containing a unified call interface, wherein the parameters of the unified call interface include a library index and a function identifier; generating a unified dispatch function in the Native layer based on the library index and the function identifier, wherein the unified dispatch function is used to call the corresponding Native function library and operation function based on the library index and the function identifier; generating a bridge file connecting the JAVA layer and the Native layer based on the JAVA class, wherein the bridge file is used to map the call of the unified call interface to the unified dispatch function; obtaining the Native function library in binary format corresponding to the library index and the function identifier; and compiling and linking the bridge file, the Native function library, and the original JAVA operating system project together to generate the recompiled JAVA operating system.

[0007] In the above implementation process, a unified JAVA call interface is used to stabilize the interaction contract between the Applet and the operating system. A statically defined interface, an automatically generated bridge layer, and one or more third-party binary libraries are deeply integrated and solidified into a unified recompiled JAVA operating system through compilation and linking, thereby improving the stability of JAVA card calling native functions.

[0008] Optionally, in this embodiment of the application, generating a bridge file connecting the JAVA layer and the Native layer based on a JAVA class includes: parsing a JAVA class containing a unified calling interface using an automated tool to generate a bridge file connecting the JAVA layer and the Native layer.

[0009] In the above implementation process, the traditionally error-prone and time-consuming process of manually writing code is reduced. The tool automatically completes the accurate mapping and conversion from JAVA classes to bridge file implementations, improving the efficiency and accuracy of bridge layer code generation.

[0010] Optionally, in this embodiment of the application, the function call request is initiated by the on-card application of the JAVA card. The on-card application initiates the request by referencing the software package containing the unified call interface and calling the unique static function corresponding to the unified call interface.

[0011] In the above implementation process, by providing a fixed and unified calling interface, the complexity of on-card applications accessing underlying native functions is simplified. Developers and callers do not need to understand the implementation details of different functional modules. They only need to master the unified calling method to access all native functions, which improves code readability and the convenience of calling native functions.

[0012] Optionally, in this embodiment of the application, the unified distribution function calls the operation function in the corresponding Native function library according to the library index and the function identifier, and executes the target Native function through the operation function, including: the unified distribution function determines the target Native function library according to the library index; calls the operation function from the target Native function library according to the function identifier, and executes the target Native function through the operation function.

[0013] In the above implementation process, a hierarchical routing mechanism composed of library indexes and function identifiers is used to maintain a unified single call entry point while achieving precise scheduling of diverse native functions, thus improving the system's efficiency in handling cross-function requests. Furthermore, it ensures consistency and reliability in interactions between different functional modules, providing support for building a high-performance, highly cohesive, and loosely coupled native function call system.

[0014] Optionally, in this embodiment of the application, after generating the recompiled JAVA operating system, the method further includes: obtaining the updated Native function library; generating the updated Native function library by adding, deleting, or modifying the Native functions in the original Native function library; compiling and linking the bridging file, the updated Native function library, and the original JAVA operating system project together to generate the updated JAVA operating system; and using the updated JAVA operating system to receive subsequent function call requests initiated based on a predefined unified call interface.

[0015] In the above implementation process, by replacing the native function library and recompiling the system, the upgrade and maintenance of native functions become standardized and automated, simplifying the system update process. This update method completely shields changes to the lower-level native functions from the bridging layer and unified interface, allowing upper-level applications to transparently use the updated functions without any modifications, thus improving system maintainability and the convenience of function updates.

[0016] Optionally, in this embodiment, the library index is used to identify different Native function libraries; the function identifier is used to identify the target Native function in the Native function library.

[0017] In the above implementation process, a hierarchical addressing mechanism combining library indexes and function identifiers was adopted to establish a clear and standardized function addressing path. This enables upper-layer calls to quickly and accurately locate the specific function implementation, improving the efficiency and accuracy of function calls. The dual-identifier structure maintains a highly simplified interface while providing strong system scalability. Adding new function libraries or expanding the functionality of existing libraries only requires updating the routing mapping at the corresponding level, without changing the existing call interfaces and architectural design, significantly reducing the complexity and maintenance costs of system function expansion.

[0018] Secondly, embodiments of this application also provide an apparatus for a JAVA card to call native functions, comprising: a request receiving module, configured to receive a function call request initiated by the JAVA card to a recompiled JAVA operating system based on a predefined unified call interface, the function call request being used to call a target native function, the function call request including a library index and a function identifier; the recompiled JAVA operating system integrating a bridging file generated according to the unified call interface, the bridging file being mapped to the native layer, and the recompiled JAVA operating system pre-linking one or more native function libraries; and a response module, configured to respond to the function call request by the recompiled JAVA operating system routing the function call request to a unified dispatch function in the native layer through bridging mapping, and the unified dispatch function calling an operation function in the corresponding native function library according to the library index and function identifier, thereby executing the target native function through the operation function.

[0019] Thirdly, embodiments of this application also provide a computer program product, including computer program instructions, which are executed by a processor to perform the method provided in the first aspect or any implementation thereof.

[0020] Fourthly, embodiments of this application also provide an electronic device, including: a processor and a memory, the memory storing computer program instructions, which are executed by the processor to perform the method provided in the first aspect or any implementation thereof.

[0021] Fifthly, embodiments of this application also provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, perform the method provided in the first aspect or any implementation thereof.

[0022] This application provides a method, program product, electronic device, and storage medium for calling native functions from a Java card. By defining a fixed and unchanging unified calling interface, it fundamentally reduces the problem of frequent interface changes caused by function expansion or modification, and lowers the coupling between the Java card and native functions. A two-level routing mechanism based on library indexes and function identifiers, combined with automatically generated bridge mappings, achieves an efficient and automated request distribution process, accurately routing general Java layer requests to the corresponding native functions, improving calling efficiency and system automation. It also supports directly pre-linking third-party binary native libraries into the system, allowing different vendors to independently and concurrently develop, test, and upgrade their functional modules without disclosing the source code, effectively protecting the source code of all parties and providing a highly flexible and easily maintainable method for calling native functions from a Java card. Attached Figure Description

[0023] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 A flowchart illustrating a method for a JAVA card to call native functions, provided as an embodiment of this application;

[0025] Figure 2 This application provides a schematic diagram of the structure of a device for calling native functions using a JAVA card;

[0026] Figure 3 The present application provides a schematic diagram of the structure of an electronic device. Detailed Implementation

[0027] The embodiments of the technical solution of this application will now be described in detail with reference to the accompanying drawings. These embodiments are only used to more clearly illustrate the technical solution of this application and are therefore merely examples, and should not be used to limit the scope of protection of this application.

[0028] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this application.

[0029] In the description of the embodiments of this application, technical terms such as "first" and "second" are used only to distinguish different objects and should not be construed as indicating or implying relative importance or implicitly specifying the number, specific order, or primary and secondary relationship of the indicated technical features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly defined.

[0030] A JAVA card is a smart card capable of running JAVA programs. Its core is a simplified JAVA Card Operating System (JAVA COS) that streamlines the Java Virtual Machine (JCVM). Compared to traditional smart cards, the main advantages of JAVA cards lie in their support for dynamic downloading and secure isolation of multiple applications (i.e., multiple applets on multiple cards). Furthermore, they provide a unified and secure operating environment for applets through the standard JAVA Card API, enhancing development convenience and card portability.

[0031] However, this standardized design also brings its inherent limitations. The standard Java Card API has a fixed and limited function set, mainly focusing on basic encryption algorithms, communication, and memory management. But in many high-security, highly customized application scenarios, it is often necessary to integrate non-standard, customized functional modules, such as Chinese national cryptographic algorithms (SM2 / SM3 / SM4), specific security protocols, or unique functions tightly bound to hardware. These customized functions cannot be implemented through the standard Java Card API and must be accomplished by calling native function libraries written in languages ​​such as C / C++ that interact directly with the underlying hardware.

[0032] Existing technical solutions typically extend Java Card Optimization (COS), creating new, non-standard Java extension APIs for specific native functionalities outside of the standard Java Card API. This approach follows typical object-oriented programming principles: defining one or more Java packages for each new functional module, creating multiple classes within each package, and defining corresponding symbolic constants, data members, and member methods (i.e., Java Native methods) within each class. These Java Native methods are then bound and invoked at the underlying level through the JCVM's Native interface with the C / C++ code implementing the specific functionality.

[0033] While this approach enables functional expansion, it also introduces several problems. First, when both the native functional modules and the on-card applications of the JAVA card are developed by third-party vendors and need to be integrated into the JAVA COS platform vendor's environment, the complexity of the interfaces becomes a major bottleneck. Adding, deleting, or modifying any function requires simultaneous modifications to the JAVA layer's extended API and the native layer's implementation. This tight coupling leads to frequent interface changes, making joint debugging and testing between the three parties (COS vendor, native library vendor, and Applet vendor) extremely complex and cumbersome, severely slowing down the product development cycle.

[0034] Secondly, this deep integration model makes it difficult to protect the source code of all parties involved in the collaboration. In order to integrate their functions into COS, third-party native library vendors usually need to expose the source code of their key algorithms or logic to the COS vendor. Conversely, COS vendors may also need to disclose some internal interface details, which brings a huge risk of source code leakage.

[0035] Finally, because applets are programmed directly using these specific, fine-grained extended API interfaces, any upgrade or modification to the underlying native function library almost inevitably leads to changes in the corresponding Java interfaces. This forces applets calling those interfaces to also undergo corresponding modifications and retesting, resulting in a lack of necessary flexibility and maintainability. Therefore, the industry urgently needs a new native function calling solution that can achieve interface stability, support binary integration, and effectively promote cross-vendor parallel development.

[0036] This application provides a method for a Java card to call native functions. By defining a fixed and unchanging unified calling interface, it fundamentally reduces the problem of frequent interface changes caused by function expansion or modification, and lowers the coupling between the Java card and native functions. A two-level routing mechanism based on library indexes and function identifiers, combined with automatically generated bridge mappings, achieves an efficient and automated request distribution process, accurately routing general requests from the Java layer to the corresponding native functions, improving calling efficiency and system automation. It also supports directly pre-linking third-party binary native libraries into the system, allowing different vendors to independently and concurrently develop, test, and upgrade their functional modules without disclosing the source code, effectively protecting the source code of all parties and providing a highly flexible and easily maintainable method for a Java card to call native functions.

[0037] Please see Figure 1 The illustrated diagram shows a flowchart of a method for a Java card to invoke native functions according to an embodiment of this application. This method can be applied to electronic devices, which may include physical devices such as servers, PCs, tablets, or smartphones, or virtual devices such as virtual machines or containers. The electronic device can be a single device, a combination of multiple devices, or a cluster of a large number of devices. The method for a Java card to invoke native functions may include:

[0038] Step S110: Receive a function call request initiated by the JAVA card based on a predefined unified call interface to the recompiled JAVA operating system. The function call request is used to call the target Native function and includes a library index and function identifier. The recompiled JAVA operating system integrates a bridge file generated according to the unified call interface. The bridge file is mapped to the Native layer, and the recompiled JAVA operating system pre-links one or more Native function libraries.

[0039] Step S120: In response to the function call request, the recompiled JAVA operating system routes the function call request to the unified dispatch function in the Native layer through bridging mapping. The unified dispatch function then calls the operation function in the corresponding Native function library according to the library index and function identifier, and executes the target Native function through the operation function.

[0040] In step S110, the JAVA card is a smart card capable of running JAVA programs. Its core is a simplified Java Virtual Machine (JCVM) and an operating system (JAVA COS). The JAVA card initiates function call requests through on-card applications (applets) based on a predefined unified calling interface. Native functions mainly refer to native methods implemented without JAVA code, used to access operating system functions, interact with hardware, or optimize performance.

[0041] A predefined unified invocation interface is a unique, static public function designed at the Java layer. For example, the function prototype of the unified invocation interface can be defined as `Nativelib(short libIndex, shortfunctionID, byte[]inBuffer, short inOffset, short inLen, byte[]outBuffer)`. Its parameters are general and structured. `libIndex` is a short integer used as a library index to distinguish different hardware functional modules or third-party libraries in the system; for example, a value of 1 represents an encryption algorithm library, and a value of 2 represents a communication protocol library. `functionID` is the second short integer parameter, serving as a function identifier. Within the library determined by `libIndex`, the function identifier further specifies the specific function to be invoked; for example, in an encryption algorithm library, a value of 1 represents AES encryption, and a value of 2 represents SHA256 hash calculation. As one implementation method, the unified calling interface can also include other parameters. For example, inBuffer and outBuffer are two byte arrays, which serve as general containers for input and output data, respectively; inOffset and inLen precisely specify the starting position and length of the input data in inBuffer, realizing the accurate transfer of data blocks.

[0042] When an on-card application in a Java card needs to call a native function, it can directly invoke this unified interface based on the library index and function identifier. For example, the on-card application, according to the specifications agreed upon with the Java operating system and native library vendors beforehand, fills in the correct library index and function identifier, fills in the data to be processed in the specified input location, and reserves output space for the received results. This call request is then captured by the Java Card Virtual Machine (JCVM) of the recompiled Java operating system. At this time, the system environment is the "recompiled Java operating system," which is a system image pre-integrated during the manufacturing stage. It not only includes standard Java COS functions, but also, through compilation and linking, solidifies the "bridging file" (an automatically generated C code file that implements Java Native method bindings) and all the necessary "native function libraries" (binary library files provided by third parties that implement specific functions) together, thus preparing a complete execution path for this call.

[0043] In step S120, after the call request enters the Java Virtual Machine (JVM), the recompiled JVM uses the integrated "bridging mapping" mechanism to translate it to the Native layer. For example, the "bridging file" created during system generation comes into play at this point. The bridging file contains a bridging function that strictly corresponds to the JVM's unified dispatch function. The JCVM calls this bridging function, which performs cross-language data type conversion: for example, converting a JVM byte array and its offset and length information into byte pointers (U8*) and memory addresses that can be directly manipulated in C. After the conversion is complete, the bridging function then calls the unified dispatch function implemented in the Native layer.

[0044] The unified dispatch function internally implements first-level routing through a first-level array of function pointers using library indices (libIndex) as keys. Each element of this array corresponds to a specific native library. After retrieving the entry point of the target library from the first-level array based on the library index, a second-level routing is implemented using a second-level array of function pointers (or a large switch-case statement) using function IDs as keys. This ultimately locates and jumps to the address of the operation function within that library that precisely corresponds to the function ID. This multi-level function pointer array-based lookup and jump mechanism constitutes an efficient and deterministic two-level routing path.

[0045] After execution, the operation function usually returns a status code (such as success, failure, and error reason). This status code will follow the call chain, from the operation function to the unified dispatch function, and then to the bridging function. Finally, it will be converted and used as the return value of the JAVA layer, and fed back to the application on the original JAVA card, thus completing the call.

[0046] In the implementation of the above embodiments: by defining a fixed and unchanging unified calling interface, the problem of frequent interface changes caused by function expansion or modification is fundamentally reduced, and the coupling between the JAVA card and native functions is lowered. A two-level routing mechanism based on library indexes and function identifiers, combined with automatically generated bridge mappings, achieves an efficient and automated request distribution process, accurately routing general JAVA layer requests to the corresponding native functions, improving calling efficiency and the system's automation level.

[0047] Furthermore, the unified calling interface (including its package, class, function name, and parameter structure) plays a stable and unchanging core contract role in the entire system architecture. Regardless of whether the underlying native function library is an initial integration, a subsequent update (including the addition, deletion, or modification of functions), or provided by different third-party vendors, as long as it follows and routes through the established semantics of the library index (libIndex) and function identifier (functionID), the upper-layer Java Card Operating System (JAVA COS) and on-card applications (Applets) do not require any code modification or recompilation. This architecture fundamentally ensures that changes to the underlying native function implementation are completely shielded by the unified interface and routing mechanism, improving the maintainability, scalability, and independent iteration capability of modules in cross-vendor collaboration scenarios.

[0048] Optionally, in this embodiment of the application, before receiving the function call request initiated by the JAVA card to the recompiled JAVA operating system based on a predefined unified call interface, the method further includes:

[0049] This retrieves a predefined Java class containing a unified invocation interface. The unified invocation interface takes two parameters: a library index and a function identifier. The Java class is defined as a static public function. The "library index" is an integer parameter used to logically distinguish different functional modules, such as specifying whether the call is for the encryption module, file system module, or communication module. The "function identifier" is a second integer parameter used to identify a specific function from the library index; for example, in the encryption module, it distinguishes between AES encryption and RSA signing.

[0050] Based on the library index and function identifier, a unified dispatch function is generated in the Native layer. The unified dispatch function is used to call the corresponding Native function library and operation function according to the library index and function identifier.

[0051] The unified dispatch function can be a function implemented in C / C++. It is the mirror and processor of the unified interface in the Java layer at the native layer. The unified dispatch function needs to be manually written and implemented by the Java COS vendor during the system development phase. The core task of the unified dispatch function is to complete the routing logic of "calling the corresponding native function library and operation function based on the library index and the function identifier".

[0052] For example, this can be achieved using a two-level routing mechanism. First, the function would have a primary dispatch structure, such as a switch statement or an array of function pointers with libIndex as the key, to perform the first level of routing—selecting a target "native function library" based on the "library index." Then, for each library index, there would be a second level of dispatch structure, such as another switch statement, which would ultimately jump to the corresponding "operation function" within that library that implements the specific functionality based on the "function identifier."

[0053] A bridge file is generated based on Java classes, connecting the Java layer and the Native layer. This bridge file maps calls to a unified API to a unified dispatch function. The bridge file consists of automatically generated C source code and header files that bind Java's Native method calls to specific C / C++ implementations. Its core function is "mapping," responsible for converting and passing the Java call's environment, objects, and data types to C language data types and pointers that the Native layer can directly handle. This process of "generating a bridge file based on the Java class" can be achieved using dedicated Native tasks in build tools (Native2JAVA or similar plugins) or specific commands provided in the Java Development Kit (JDK).

[0054] One implementation involves configuring the tool in the build script, specifying the Java class containing the "unified invocation interface" as input. The tool parses this class, identifies the declared native methods, and then automatically generates the corresponding bridging file based on a fixed template.

[0055] Retrieves the native function library in binary format, corresponding to the library index and function identifier. The binary format native function library is an independently developed third-party vendor, compiled and linked using a native code compiler, and is a directly executable machine code file. The native function library contains the concrete implementations of the "operation functions," which are the functions actually performing encryption, storage, and other tasks, called by the unified distribution function. The operation functions and the unified distribution function are associated through the "library index" and "function identifier."

[0056] The bridging files, native function libraries, and the original Java operating system project are compiled and linked together to generate a recompiled Java operating system.

[0057] The original Java operating system project consists of the Java and C source code of COS. Compilation and linking are automated processes driven by build tools such as Make or Apache Ant. First, the compiler compiles the C source files in the "original Java operating system project" and the C source files in the "bridging files" into object files respectively. Then, the linker starts working, merging all the object files generated in the first step, as well as all the "binary native function libraries" provided by third parties, into a single executable file, generating the recompiled Java operating system.

[0058] In the implementation of the above embodiments: a unified JAVA call interface is used to stabilize the interaction contract between the Applet and the operating system. A statically defined interface, an automatically generated bridge layer, and one or more third-party binary libraries are deeply integrated and solidified into a unified recompiled JAVA operating system through compilation and linking, thereby improving the stability of JAVA card calling native functions.

[0059] Optionally, in this embodiment of the application, generating a bridge file connecting the JAVA layer and the Native layer based on JAVA classes includes:

[0060] An automated tool parses a Java class containing a unified API and generates a bridge file that connects the Java layer and the Native layer.

[0061] The input is a "Java class containing a unified calling interface," that is, a Java source code file predefined by the developer that declares at least one method. The automation tool can be a specific program or plugin integrated into the project build process, such as a dedicated command-line tool. Designed specifically for code generation in a Java environment, the automation tool first "parses" the Java class. This process can be viewed as a simplified compiler front-end: the tool reads the Java source code, performs lexical and syntactic analysis, constructs the abstract syntax tree (AST) of the class, and precisely identifies all method declarations modified by the `Native` keyword, extracting key information including the method name, return type, and the types and order of all parameters.

[0062] The tool will automatically generate a C function with specific naming rules based on the parsed method signature. The parameter list of the C function will strictly correspond to the JAVA method, and a C source file will be generated.

[0063] In the implementation of the above embodiments: the traditionally error-prone and time-consuming process of manually writing code is reduced, and the tool automatically completes the accurate mapping and conversion from JAVA classes to bridge file implementation, thereby improving the efficiency and accuracy of bridge layer code generation.

[0064] Optionally, in this embodiment of the application, the function call request is initiated by the on-card application of the JAVA card. The on-card application initiates the request by referencing the software package containing the unified call interface and calling the unique static function corresponding to the unified call interface.

[0065] An applet is a small Java program that runs on the Java Card operating system and is responsible for implementing specific business logic, such as authentication and electronic payment. When these apps need to access hardware-specific functions or custom algorithms that are beyond the scope of the standard Java Card API, they can initiate a call through this mechanism.

[0066] The on-card application initiates a request by filling in the library index of the target functional module and the function identifier of the specific operation within the specified module, calling the unique static function corresponding to the unified call interface. When the on-card application executes this static function call, the Java Card Virtual Machine (JCVM) intercepts the call and initiates subsequent cross-layer processing. This design completely encapsulates the complex low-level call details behind a simple function call, providing convenience for upper-layer application developers.

[0067] In the implementation of the above embodiments: by providing a fixed and unified calling interface, the complexity of on-card applications accessing underlying Native functions is simplified. Developers and callers do not need to understand the implementation details of different functional modules. They only need to master the unified calling method to access all Native functions, which improves the readability of the code and the convenience of calling Native functions.

[0068] Optionally, in this embodiment, the unified distribution function calls the corresponding operation function in the Native function library according to the library index and function identifier, and executes the target Native function through the operation function, including:

[0069] The unified distribution function determines the target native function library based on the library index; it then calls the operation function from the target native function library based on the function identifier, and executes the target native function through the operation function.

[0070] The unified dispatch function is a core routing function implemented in the Native layer. Internally, it uses predefined routing logic and employs a hierarchical array of function pointers or a switch-case conditional branching structure to perform precise task scheduling. When the unified dispatch function is called, it first parses the passed "library index" parameter (an integer identifier used to logically distinguish different functional modules). By looking up the internal mapping table or performing conditional checks, it determines the "target Native functional library" corresponding to that index value, which is a pre-compiled binary module that implements a specific set of functionalities, such as an encryption / decryption library or a security library.

[0071] After successfully routing to the target library, the dispatch function then parses the "function identifier" parameter (an integer code that uniquely identifies a specific function within the library) and performs a second-level routing based on it. This involves calling the precisely bound "operation function" from the target library—the underlying function that actually performs hardware operations or complex algorithm calculations. Finally, this operation function receives the parameters from the input data buffer, performs the specific operations of the "target native function," such as password calculation or secure storage access, writes the processing result to the output data buffer, and simultaneously passes the execution status to the next level in the call chain via the return value.

[0072] In the implementation of the above embodiments: a hierarchical routing mechanism composed of library indexes and function identifiers is used to achieve precise scheduling of diverse native functions while maintaining a unified single call entry point, thereby improving the system's efficiency in handling cross-functional requests. Furthermore, it ensures consistency and reliability of interactions between different functional modules, providing support for building a high-performance, highly cohesive, and loosely coupled native function call system.

[0073] Optionally, in this embodiment of the application, after generating the recompiled JAVA operating system, the method further includes:

[0074] Obtain the updated Native library; the updated Native library is generated by adding, deleting, or modifying Native functions in the original Native library. The updated Native library refers to a new binary library file generated by recompiling the source code of the original Native library after adding, deleting, or modifying functions.

[0075] For example, third-party vendors may develop new C / C++ source code based on new requirements or bug fixes: they may add new function names, which will be assigned new function identifiers; they may also delete functions with security vulnerabilities; or they may modify the internal implementation logic of existing functions to optimize performance or fix defects.

[0076] The bridging files, the updated native function libraries, and the original JAVA operating system project are compiled and linked together to generate the updated JAVA operating system. The updated JAVA operating system is used to receive subsequent function call requests based on a predefined unified call interface.

[0077] The bridging file remains unchanged because the definition of the unified call interface has not changed; "Original JAVA operating system project" refers to the JAVA COS source code project that does not include the Native library updated in this project.

[0078] The compilation and linking process, for example, compiles the C source code of the JAVA COS core source code and the bridging file into object files; then, these newly generated object files, the updated native function libraries, and other unchanged library files in the system are handed over to the linker; the linker resolves all symbol references, replaces the corresponding parts in the old version with the updated native function libraries, and finally generates a complete "updated JAVA operating system" image file containing updated functions. This new system image will replace the original system and be used to handle all subsequent call requests initiated through the unified call interface.

[0079] The embodiments of this application encapsulate the function addressing logic inside the dispatch function, so that when adding or replacing a function module, only the internal routing mapping needs to be updated, without changing the general calling interface, which greatly enhances the scalability and modularity of the system and reduces the complexity of system function iteration and maintenance.

[0080] In the implementation of the above embodiments: by replacing the native function library and recompiling the system, the upgrade and maintenance of native functions become standardized and automated, simplifying the system update process. This update method completely shields changes to the lower-level native functions from the bridging layer and unified interface, allowing upper-level applications to transparently use the updated functions without any modifications, thus improving system maintainability and the convenience of function updates.

[0081] Optionally, in this embodiment, the library index is used to identify different Native function libraries; the function identifier is used to identify the target Native function in the Native function library.

[0082] The library index is a predefined integer parameter that serves as a logical partition identifier at the system level, uniquely identifying a target library among multiple native function libraries. In technical implementation, the system architect establishes a library index allocation table during the design phase, assigning a fixed index number to each functional module, such as an encryption algorithm library, a security library, or a communication protocol library. When the unified dispatch function receives a call request, it parses the library index parameter and uses switch-case conditional statements or function pointer array lookups to guide the program execution flow to the corresponding native function library entry point. The function identifier is another integer parameter that serves as a function addressing identifier within the library, precisely locating a specific target native function and its corresponding operation function within a given native function library.

[0083] In the implementation of the above embodiments: by adopting a hierarchical addressing mechanism combining library indexes and function identifiers, a clear and standardized function addressing path is established, enabling upper-layer calls to quickly and accurately locate specific function implementations, thus improving the efficiency and accuracy of function calls. The dual-identifier structure, while maintaining a highly simplified interface, provides the system with strong scalability. Adding new function libraries or expanding the functionality of existing libraries only requires updating the routing mapping at the corresponding level, without changing the existing call interfaces and architectural design, significantly reducing the complexity and maintenance costs of system function expansion.

[0084] Please see Figure 2 The diagram shown is a structural schematic of a device for calling native functions using a JAVA card, as provided in an embodiment of this application. This application provides a device 200 for calling native functions using a JAVA card, comprising:

[0085] The request receiving module 210 is used to receive function call requests initiated by the JAVA card to the recompiled JAVA operating system based on a predefined unified call interface. The function call request is used to call the target Native function and includes a library index and a function identifier. The recompiled JAVA operating system integrates a bridge file generated according to the unified call interface. The bridge file is mapped to the Native layer, and the recompiled JAVA operating system pre-links one or more Native function libraries.

[0086] The response module 220 is used to respond to function call requests. The recompiled JAVA operating system routes the function call request to the unified dispatch function in the Native layer through bridging mapping. The unified dispatch function then calls the operation function in the corresponding Native function library according to the library index and function identifier, and executes the target Native function through the operation function.

[0087] Optionally, in this embodiment, the device 200 for calling Native functions from a JAVA card further includes a recompilation module, used to obtain a predefined JAVA class containing a unified calling interface, the parameters of which include a library index and a function identifier; generate a unified dispatch function in the Native layer based on the library index and function identifier, the unified dispatch function being used to call the corresponding Native function library and operation function based on the library index and function identifier; generate a bridge file connecting the JAVA layer and the Native layer based on the JAVA class, the bridge file being used to map the calls of the unified calling interface to the unified dispatch function; obtain the Native function library in binary format corresponding to the library index and function identifier; and compile and link the bridge file, the Native function library, and the original JAVA operating system project together to generate a recompiled JAVA operating system.

[0088] Optionally, in this embodiment of the application, the device 200 for calling Native functions of a JAVA card, the recompilation module, is further used to parse the JAVA class containing the unified calling interface through an automated tool to generate a bridge file connecting the JAVA layer and the Native layer.

[0089] Optionally, in this embodiment of the application, the device 200 for calling native functions from a JAVA card initiates the function call request by the on-card application of the JAVA card. The on-card application initiates the request by referencing a software package containing a unified calling interface and calling the unique static function corresponding to the unified calling interface.

[0090] Optionally, in this embodiment of the application, the device 200 for calling Native functions by a JAVA card includes a response module, which is used to determine the target Native function library by a unified distribution function based on the library index; call the operation function from the target Native function library based on the function identifier; and execute the target Native function through the operation function.

[0091] Optionally, in this embodiment of the application, the device 200 for calling Native functions by a JAVA card further includes an update module for obtaining an updated Native function library; the updated Native function library is generated by adding, deleting, or modifying Native functions in the original Native function library; the bridging file, the updated Native function library, and the original JAVA operating system project are compiled and linked together to generate an updated JAVA operating system; the updated JAVA operating system is used to receive subsequent function call requests initiated based on a predefined unified call interface.

[0092] Optionally, in this embodiment of the application, the device 200 for calling Native functions by a JAVA card uses a library index to identify different Native function libraries; and a function identifier to identify the target Native function in the Native function library.

[0093] It should be understood that this device corresponds to the above-described method embodiment for calling Native functions from a JAVA card, and is capable of executing the various steps involved in the above method embodiment. The specific functions of this device can be found in the description above, and detailed descriptions are omitted here to avoid repetition. The device includes at least one software function module that can be stored in memory or embedded in the device's operating system (OS) in the form of software or firmware.

[0094] Please see Figure 3 The present application provides a schematic diagram of the structure of an electronic device according to an embodiment of the present application. An electronic device 300 provided in this application includes a processor 310 and a memory 320. The memory 320 stores machine-readable instructions executable by the processor 310. When the machine-readable instructions are executed by the processor 310, the above-described method is performed.

[0095] Figure 3 The components shown can be implemented using hardware, software, or a combination thereof. Electronic device 300 may be a physical device, such as a server or PC, or a virtual device, such as a virtual machine or virtualization container. Furthermore, electronic device 300 is not limited to a single device; it can also be a combination of multiple devices or a cluster of a large number of devices.

[0096] This application also provides a storage medium storing a computer program, which is executed by a processor to perform the above-described method.

[0097] The storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Red-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0098] This application also provides a computer program product, including computer program instructions, which are executed by a processor to perform the method described above.

[0099] It should be understood that the disclosed apparatus and methods can also be implemented in other ways, given the several embodiments provided in this application. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, or they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0100] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0101] The above description is only an optional implementation of the embodiments of this application, but the protection scope of the embodiments of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the embodiments of this application should be covered within the protection scope of the embodiments of this application.

Claims

1. A method for calling native functions from a Java card, characterized in that, include: The system receives a function call request initiated by the JAVA card to the recompiled JAVA operating system based on a predefined unified call interface. The function call request is used to call a target native function and includes a library index and a function identifier. The recompiled JAVA operating system integrates a bridging file generated according to the unified call interface. The bridging file is mapped to the native layer, and the recompiled JAVA operating system pre-links one or more native function libraries. In response to the function call request, the recompiled JAVA operating system routes the function call request to the unified dispatch function of the Native layer through bridging mapping. The unified dispatch function then calls the corresponding operation function in the Native function library according to the library index and the function identifier, and executes the target Native function through the operation function.

2. The method according to claim 1, characterized in that, Before receiving a function call request initiated by the JAVA card to the recompiled JAVA operating system based on a predefined unified call interface, the method further includes: Obtain a predefined Java class that contains the unified call interface, wherein the parameters of the unified call interface include the library index and the function identifier; Based on the library index and the function identifier, the unified dispatch function is generated in the Native layer. The unified dispatch function is used to call the corresponding Native function library and operation function according to the library index and the function identifier. Based on the JAVA class, a bridge file is generated connecting the JAVA layer and the Native layer. The bridge file is used to map the calls of the unified call interface to the unified dispatch function. Obtain the Native function library in binary format corresponding to the library index and the function identifier; The bridging file, the native function library, and the original JAVA operating system project are compiled and linked together to generate the recompiled JAVA operating system.

3. The method according to claim 2, characterized in that, Based on the Java class, a bridge file connecting the Java layer and the Native layer is generated, including: An automated tool is used to parse the Java class containing the unified calling interface and generate a bridge file connecting the Java layer and the Native layer.

4. The method according to claim 1, characterized in that, The function call request is initiated by the on-card application of the JAVA card. The on-card application initiates the request by referencing the software package containing the unified call interface and calling the unique static function corresponding to the unified call interface.

5. The method according to claim 1, characterized in that, The unified distribution function calls the corresponding operation function in the Native function library according to the library index and the function identifier, and executes the target Native function through the operation function, including: The unified distribution function determines the target native function library based on the library index; The operation function is called from the target Native function library according to the function identifier, and the target Native function is executed through the operation function.

6. The method according to claim 2, characterized in that, After generating the recompiled Java operating system, the method further includes: Obtain the updated Native function library; the updated Native function library is generated by adding, deleting or modifying Native functions in the original Native function library; The bridging file, the updated Native function library, and the original JAVA operating system project are compiled and linked together to generate the updated JAVA operating system; the updated JAVA operating system is used to receive subsequent function call requests initiated based on a predefined unified call interface.

7. The method according to claim 1, characterized in that, The library index is used to identify different Native function libraries; the function identifier is used to identify the target Native function in the Native function library.

8. A computer program product, characterized in that, It includes computer program instructions that, when executed by a processor, perform the method as described in any one of claims 1 to 7.

9. An electronic device, characterized in that, include: A processor and a memory, the memory storing computer program instructions that, when executed by the processor, perform the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions that, when executed by a processor, perform the method as described in any one of claims 1 to 7.

Images