Persistent simulation method and device for Java Card simulator

Abstract

The invention discloses a persistent simulation method and device for a Java Card simulator, and relates to the technical field of persistent simulation. The method comprises the following steps: if a serialized object state does not exist, initializing a Java Card simulator environment, traversing a target object graph from a root node of the target object graph during persistent simulation of the Java Card simulator, and creating state representation of each object to be concerned; creating an object state list according to the state representation of each to-be-concerned object, and creating an instance reference relationship maintenance list based on the object state list; and analyzing the instance reference relationship maintenance list to obtain an instance loading sequence, and loading the application instance according to the instance loading sequence. According to the technical scheme provided by the embodiment of the invention, the development complexity during persistent simulation of the Java Card simulator can be reduced, and a cross-instance reference scene can be accurately simulated.

Description

Technical Field

[0001] This invention relates to the field of persistent simulation technology, and in particular to a persistent simulation method and device for a Java Card simulator. Background Technology

[0002] Java Card is a lightweight Java platform designed specifically for smart cards (such as identity cards, bank cards, and electronic passports) and embedded security chips, allowing developers to write portable secure applications. The Java Card simulator is a key tool for developing smart card applications, used to test and verify the functionality and security of applications in a non-real hardware environment. Smart cards rely on non-volatile storage units to store critical data (keys, counters, transaction records, etc.), which have unique characteristics. Non-volatile storage units have a physical write / erase lifespan, extremely small storage space, and data must be retained long-term even when the device is powered off. This ensures accurate simulation of the operating environment and non-volatile storage characteristics of a real smart card, guaranteeing consistent application logic behavior in the simulated environment and in real hardware. The simulator needs to perform persistent simulation; otherwise, developers cannot verify the impact of these non-volatile storage characteristics on the application. The Java Card simulator's persistent simulation simulates non-volatile memory by saving persistent data to disk files and loading this data when needed. This mechanism allows developers to test the storage and retrieval functions of persistent data during development without relying on actual hardware cards, helping developers accelerate development cycles and reduce development costs.

[0003] Persistent simulation serves as a bridge between the virtual and real worlds in Java Card development. It ensures that tests performed on an application in a simulated environment (such as data persistence, resource constraints, and exception recovery) accurately reflect its behavior in the hardware, thus avoiding the fatal problem of "simulation passes, actual failure." A lack of persistence functionality in the simulator can lead to various issues, such as the application running normally in the simulator but crashing in real hardware due to incorrect data persistence; unexposed resource abuse leading developers to mistakenly believe storage space is "unlimited," resulting in functional abnormalities due to insufficient space during actual deployment; and frequent manual reconstruction of test scenarios making it difficult to verify complex cross-session logic, leading to a surge in debugging costs. For smart card applications that rely on state continuity and strict resource management, tests lacking persistent simulation are almost equivalent to ineffective tests.

[0004] Currently, many Java Card simulators rely on manually defining a list of classes for state recording, which increases development complexity. Summary of the Invention

[0005] This invention provides a persistent simulation method and device for a Java Card simulator, to solve the problem of high development complexity caused by manually recording state during persistent simulation of a Java Card simulator.

[0006] According to one aspect of the present invention, a persistent simulation method for a Java Card simulator is provided, comprising:

[0007] If no serialized object state exists, the Java Card simulator environment is initialized, and the target object graph is traversed starting from the root node of the target object graph during Java Card simulator persistence simulation, creating state representations for each object of interest.

[0008] Based on the state representation of each object to be monitored, create an object state list, and based on the object state list, create an instance reference relationship maintenance list;

[0009] The instance reference relationship maintenance list is parsed to obtain the instance loading order, and the application instances are loaded according to the instance loading order.

[0010] According to another aspect of the present invention, a persistent simulation device for a Java Card simulator is provided, comprising:

[0011] The state representation module is used to initialize the smart card Java Card simulator environment if there is no serialized object state, and to traverse the target object graph from the root node of the target object graph when the Java Card simulator persists the simulation, creating state representations for each object of interest.

[0012] The maintenance list creation module is used to create an object status list based on the status representation of each object to be monitored, and to create an instance reference relationship maintenance list based on the object status list.

[0013] The application instance loading module is used to parse the instance reference relationship maintenance list, obtain the instance loading order, and load the application instances according to the instance loading order.

[0014] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0015] At least one processor; and

[0016] A memory communicatively connected to the at least one processor; wherein,

[0017] The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to execute the persistent simulation method of the Java Card simulator according to any embodiment of the present invention.

[0018] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the persistent simulation method of the Java Card simulator according to any embodiment of the present invention.

[0019] According to another aspect of the present invention, a computer program product is provided, the computer program product comprising a computer program that, when executed by a processor, implements the persistent simulation method of the Java Card simulator according to any embodiment of the present invention.

[0020] The technical solution of this invention initializes the JavaCard simulator environment if no serialized object state exists. Starting from the root node of the target object graph during Java Card simulator persistence simulation, it traverses the target object graph, creating state representations for each object of interest. Based on these representations, an object state list is created, and an instance reference relationship maintenance list is generated. This list is then parsed to determine the instance loading order, and application instances are loaded according to this order. In this solution, the object state list collects the states of processed objects, and the instance reference relationship maintenance list, generated from the application instance references in the object state list, automatically determines the instance loading order. This successfully completes persistence simulation in cross-instance reference scenarios, solving the high development complexity problem associated with manually recording states during Java Card simulator persistence simulation. It reduces the development complexity of Java Card simulator persistence simulation and accurately simulates cross-instance reference scenarios.

[0021] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 A flowchart of a persistent simulation method for a Java Card simulator provided in Embodiment 1 of the present invention;

[0024] Figure 2 This is a flowchart of a persistent simulation method for a Java Card simulator provided in Embodiment 2 of the present invention;

[0025] Figure 3 This is a schematic diagram of the persistent simulation device for a Java Card simulator provided in Embodiment 4 of the present invention;

[0026] Figure 4 A schematic diagram of an electronic device that can be used to implement embodiments of the present invention is shown. Detailed Implementation

[0027] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0028] It should be noted that the terms "current," "target," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0029] Example 1

[0030] Figure 1This is a flowchart of a persistent simulation method for a Java Card simulator according to Embodiment 1 of the present invention. This embodiment is applicable to situations where the object state is automatically recorded during persistent simulation in a Java Card simulator. This method can be executed by a persistent simulation device of the Java Card simulator, which can be implemented in hardware and / or software and can be configured in an electronic device. Figure 1 As shown, the method includes:

[0031] Step 110: If no serialized object state exists, initialize the Java Card simulator environment and traverse the target object graph from the root node of the target object graph during Java Card simulator persistence simulation to create state representations for each object of interest.

[0032] The target object graph can be a core data structure in the Java Card simulator's persistent simulation. It represents a network of all active objects and their mutual references within the Java Card simulator's runtime environment at a given moment. For example, nodes in the target object graph represent object instances in memory. Object instances include application instances, ordinary object instances (non-application objects created by the application or other objects, such as data objects or utility class instances), array objects, and static fields of classes. Edges in the target object graph represent the reference relationships between nodes. Objects of interest can be objects within the target object graph.

[0033] In this embodiment of the invention, if there is no serialized object state, that is, no data copy of the object at a specific moment, the application package is installed into the simulator environment, and all classes in the application package are scanned and copied into the persistence mechanism to complete the initialization of the Java Card simulator environment. Then, the target object graph of the Java Card simulator during persistence simulation is obtained. Starting from the predefined root node, the target object graph is traversed, and a state representation is created for the objects of interest that are traversed, that is, the attribute values ​​of the objects of interest are captured and stored at the current moment.

[0034] Optionally, the initialization of the Java Card emulator environment may include: creating a corresponding directory structure in the file system based on the applet's package name, and storing each applet package in a separate folder to store all class files within that package. During loading, all class files under the same package are scanned and copied to this folder. Isolating each applet package and its class files ensures complete dependencies during loading. When loading an applet class, the system scans all class files under the same package and copies them to the corresponding folder, ensuring that all related class files are correctly loaded and stored.

[0035] Step 120: Based on the state representation of each object to be monitored, create an object state list, and based on the object state list, create an instance reference relationship maintenance list.

[0036] The object state list can be a table recording the state of objects to be monitored. For example, the object state list can record the state of objects that have already been processed. The instance reference relationship maintenance list can record information related to external application objects referenced by the current application object. For example, the instance reference relationship maintenance list includes the application object identifier and application object number of the external application object referenced by the current application object.

[0037] In this embodiment of the invention, a corresponding object state list can be created for the target object graph based on the state representation of each object to be concerned, so as to record the state of the processed objects in the object state list, thereby parsing the reference relationship of the application instances in the object state list, and creating an instance reference relationship maintenance list based on the reference relationship of the application instances in the object state list and the association information of the application instances.

[0038] Step 130: Parse the instance reference relationship maintenance list to obtain the instance loading order, and load the application instances according to the instance loading order.

[0039] The instance loading order can be the loading order of application instances.

[0040] In this embodiment of the invention, the instance reference relationship maintenance list can be parsed to obtain the dependency relationship of the application instance reference, and the instance loading order can be determined through the dependency relationship of the application instance reference, and then the application instance can be loaded according to the instance loading order.

[0041] The technical solution of this invention initializes the JavaCard simulator environment if no serialized object state exists. Starting from the root node of the target object graph during Java Card simulator persistence simulation, it traverses the target object graph, creating state representations for each object of interest. Based on these representations, an object state list is created, and an instance reference relationship maintenance list is generated. This list is then parsed to determine the instance loading order, and application instances are loaded according to this order. In this solution, the object state list collects the states of processed objects, and the instance reference relationship maintenance list, generated from the application instance references in the object state list, automatically determines the instance loading order. This successfully completes persistence simulation in cross-instance reference scenarios, solving the high development complexity problem associated with manually recording states during Java Card simulator persistence simulation. It reduces the development complexity of Java Card simulator persistence simulation and accurately simulates cross-instance reference scenarios.

[0042] Example 2

[0043] Figure 2 This is a flowchart of a persistent simulation method for a Java Card simulator provided in Embodiment 2 of the present invention. This embodiment is a specific embodiment based on the above embodiment, and provides specific optional implementation methods for creating an instance reference relationship maintenance list based on an object state list. Figure 2 As shown, the method includes:

[0044] Step 210: If no serialized object state exists, initialize the Java Card simulator environment and traverse the target object graph from the root node of the target object graph during Java Card simulator persistence simulation to create state representations for each object of interest.

[0045] In an optional embodiment of the present invention, before traversing the target object graph from the root node of the target object graph during persistent simulation in the Java Card simulator and creating state representations of each object of interest, the method may further include: obtaining object instances in the Java Card simulator environment; and creating the target object graph based on the object instances in the Java Card simulator environment and the reference relationships between the object instances.

[0046] The reference relationships between object instances include field reference relationships and array element reference relationships, etc.

[0047] In this embodiment of the invention, object instances in the Java Card simulator environment at the current moment can be obtained first, and then the reference relationships between object instances can be determined. Based on the reference relationships between object instances, the object instances in the Java Card simulator environment can be organized to obtain the target object graph.

[0048] Step 220: Based on the state representation of each object to be monitored, create an object state list, and based on the object state list, determine the object reference relationships, object identifiers, and object numbers of each application object.

[0049] Here, object references can be between application objects. Application object identifiers can be reference identifiers for application objects. Application object numbers can be the identity identifiers for application objects.

[0050] In this embodiment of the invention, after creating an object state list based on the state representation of each object to be concerned, the object state list can be parsed to extract the object reference relationship of each application object, the identifier of each application object, and the number of each application object from the object state list.

[0051] Step 230: Create an instance reference relationship maintenance list for each application object based on the object reference relationship of each application object, the identifier of each application object, and the number of each application object.

[0052] In this embodiment of the invention, the object reference relationship of the current application object, the application object identifier, and the application object number can be maintained as information in the instance reference relationship maintenance list of the current application object.

[0053] Step 240: Parse the instance reference relationship maintenance list to obtain the instance loading order, and load the application instances according to the instance loading order.

[0054] In an optional embodiment of the present invention, parsing the instance reference relationship maintenance list to obtain the instance loading order may include: creating an application instance reference topology based on the instance reference relationship maintenance list, and determining the application instance reference order based on the application instance reference topology; and using the application instance reference order as the instance loading order.

[0055] The application instance reference topology can be a topological graph describing the reference relationships between application instances that reference each other across instances. The application instance reference order can be the order in which the application instances are referenced.

[0056] In this embodiment of the invention, application object identifiers or application object numbers in the instance reference relationship maintenance list represent application instances, and object reference relationships in the instance reference relationship maintenance list are maintained according to the instance reference relationship. The application object identifiers or application object numbers representing application instances are linked in a directional manner to obtain the application instance reference topology. Based on the application instance reference topology, the application instance reference order is determined, and the application instance reference order is used as the instance loading order.

[0057] In an optional embodiment of the present invention, loading application instances according to the instance loading order may include: obtaining the application instance memory address according to each application object number, each application object identifier and memory mapping table; and loading the application instance according to the instance loading order and the application instance memory address.

[0058] The memory-mapped table can be used to look up the storage address of an application instance. The application instance's memory address can be its storage address.

[0059] In this embodiment of the invention, the application object number and the corresponding application object identifier can be combined as an attribute in a key-value pair, and the application instance memory address can be used as the attribute value in the key-value pair. Based on the key-value pair corresponding to the application object, a memory mapping table can be created. Then, when making cross-instance references, the application object number and application object identifier corresponding to the application instance whose storage address is determined as needed can be used to query the memory mapping table to obtain the application instance memory address. Thus, the application instance can be loaded according to the instance loading order and the application instance memory address.

[0060] In an optional embodiment of the present invention, after loading the application instance according to the instance loading order, the method may further include: obtaining the current state of the processed object; if the currently processed object exists in the object state list, updating the object state of the currently processed object according to the current state of the processed object; if the currently processed object does not exist in the object state list, creating an object representation of the currently processed object.

[0061] The current state of a processed object can be its latest attribute value. A currently processed object can be an application object that has already been processed.

[0062] In this embodiment of the invention, the current state of the processed object can be obtained. If the processed object exists in the object state list, the object state of the processed object is updated according to the current state of the processed object. If the processed object does not exist in the object state list, it indicates that the processed object has not established an object representation. Then, an object representation is created for the processed object.

[0063] In an optional embodiment of the present invention, the persistent simulation method of the Java Card simulator may further include performing a target file deserialization operation if a serialized object state exists.

[0064] The target file can be a serialized file.

[0065] In this embodiment of the invention, if there is a serialized object state, it indicates that there is a serialized file, i.e., a target file, and thus a deserialization operation is performed on the target file.

[0066] The technical solution of this invention initializes the JavaCard simulator environment if no serialized object state exists. Starting from the root node of the target object graph during Java Card simulator persistence simulation, it traverses the target object graph, creating state representations for each object of interest. Based on these representations, an object state list is created. Then, based on this list, the object reference relationships, identifiers, and numbers of each application object are determined. Finally, an instance reference relationship maintenance list is created based on these relationships. This list is then parsed to determine the instance loading order, and application instances are loaded according to this order. In this solution, the object state list collects the states of processed objects, and the instance reference relationship maintenance list, generated from the application instance reference relationships in the object state list, automatically determines the instance loading order. This successfully completes persistence simulation in cross-instance reference scenarios, solving the high development complexity problem associated with manually recording states during Java Card simulator persistence simulation. It reduces the development complexity of Java Card simulator persistence simulation and accurately simulates cross-instance reference scenarios.

[0067] Example 3

[0068] Embodiment 3 of the present invention provides an optional embodiment of a persistent simulation method for a Java Card simulator, the specific implementation of which can be found in the following embodiments. Technical terms that are the same as or corresponding to those in the above embodiments will not be repeated here.

[0069] In Java Card development, persistent simulation in the simulator is crucial to ensuring that application state and data are not lost after the simulator restarts or closes. Through the simulator's persistent simulation capabilities, developers can complete the development and testing of Java Card applications without relying on hardware cards, significantly improving development efficiency.

[0070] This invention provides a method for persistent simulation in a Java Card simulator. During simulator environment initialization, each Applet package is saved in a folder. When loading an Applet class, all class files under the same package are scanned and copied. When creating an Applet instance, a corresponding instance folder is created. The state of each instance needs to be saved independently to avoid mutual interference and state pollution. Furthermore, all static fields of classes are persisted to the package folder to ensure the sharing and consistency of static data across different instances. A list of instance reference relationships is also established to avoid duplicate persistence. Each Applet establishes a corresponding list of instance reference relationships, recording the application object identifier (AID) and application object number (Object ID) of its references to external objects. This determines the application instance loading order and solves the complex Applet environment simulation under cross-instance reference relationships. This allows developers to prototype and debug applications without physical hardware, helping them accelerate the development cycle and reduce development costs. The following are the main steps for implementing persistent simulation in a Java Card simulator:

[0071] 1. Initialize the emulator environment

[0072] When the simulator instance is launched, if there is a serialized object state (such as an XML file), the simulator will deserialize the target file at startup to restore the previously saved Java Card runtime environment state.

[0073] When no serialized object state exists, the Applet package is installed into the simulator environment, and all classes in the package are scanned and copied to the persistence mechanism. The Java Card simulator includes a Java Card emulation environment and an Eclipse plugin. This environment supports the latest Java Card specification and can run JavaCard applications written for earlier versions. The Java Card simulator allows developers to install Applets and simulate their behavior. Serialization is the process of converting a copy of the object state in memory into an XML file. Deserialization is the process of restoring the previously saved Java Card runtime environment state from the XML file when the simulator instance starts.

[0074] Applets can be installed using the `install Applet` method, which takes an Application Identifier (AID) and the Applet class as parameters. The specific steps are as follows:

[0075] 1) Create package files. An applet package is a software package that includes the Java Card Applet class and other related classes. It is mainly used to install and run applets in Java Card emulators or actual smart cards. An applet package typically includes multiple class files, including the main applet class and other helper classes. Classes in an applet package may also include static fields, which belong to the class itself, not instances of the class. Create a corresponding directory structure in the file system based on the applet's package name, and save each applet package in a separate folder to store all class files in that package. During loading, scan all class files under the same package and copy them to this folder. Storing each applet package and its class files in isolation ensures complete dependencies during loading.

[0076] 2) Class file scanning: When loading an Applet class, the system scans all class files in the same package and copies them to the corresponding folders to ensure that all related class files are loaded and stored correctly.

[0077] 2. Collect the status of Applet instances

[0078] An Applet instance refers to a concrete instance of an Applet running in a Java Card emulator or an actual smart card. It is an instance of the Applet class, possesses its own state and data, and has its own lifecycle, including initialization, operation, and destruction. In the persistent simulation of the Java Card emulator, collecting its state is a crucial step to ensure that the Applet instance's state and data are not lost after the emulator restarts or shuts down. The specific steps are as follows:

[0079] 1) Define the root node. According to the Java Card simulator runtime environment specification, the root node is the Java CardApplet instance and the static fields of all classes.

[0080] When creating an Applet instance, a corresponding instance folder is created. Each Applet instance has its own storage space and a unique instance identifier folder name is generated based on the AID. The instance folder is used to store all data and status information of the instance and initializes instance metadata, which includes information such as creation time and parent package. When a user creates multiple Applet instances, the status of each instance needs to be saved independently to avoid mutual interference and state pollution.

[0081] Static fields of a class are fields declared as `static` within the class. These fields belong to the class itself, not to any instance of the class. They are initialized when the class is loaded and persist until the class is unloaded. The values ​​of static fields are shared among all instances, so modifications to static fields affect all instances. All static fields of a class are persisted to the package folder, ensuring the sharing and consistency of static data across different instances.

[0082] 2) Traverse the target object graph, starting from the root node, creating a state representation for each object. An object is a concrete instance created from a class, possessing specific states and behaviors. Objects can be Applet instances or instances of other types, such as data storage objects or utility class instances. A state representation is a description or representation of an object's current state. It is typically a data structure or object used to store all relevant data and state information of the object at a given moment. The main purpose of the state representation is to accurately restore the object's original state after the simulator restarts or shuts down, which is crucial for ensuring the stability and data consistency of the Java Card application in the simulator. During the traversal of the target object graph, a state representation is created for each object. The state representation typically includes all field values ​​of the object, including primitive data types, arrays, and other object references.

[0083] Creating State Representations: During the traversal of the target object graph, a state representation is created for each object. The state representation includes all field values ​​of the object, including primitive data types, arrays, and other object references. For each object, all its fields are iterated through to determine if it already exists in the reference list. If it exists, the existing state representation is used; otherwise, a new state representation is created and scanned for copies. The reference list records the objects that have been processed and their state representations.

[0084] For example, when an object is a primitive data type, a state representation of its primitive values ​​is created.

[0085] When the object is an array, a state representation of the array is created, and each element in the array is processed recursively. Arrays include persistent and non-persistent arrays, which are handled differently. Persistent arrays are a special array type used to store temporary data. Unlike persistent arrays, they are cleared when the smart card is reset or power is lost and are not persisted to non-volatile memory (such as EEPROM or flash memory). Non-persistent arrays are suitable for storing temporary data, such as sensitive information (such as passwords or session keys). This data should be cleared immediately after use to improve security. To ensure that the simulated behavior is consistent with the actual hardware, the lifecycle of non-persistent arrays must be correctly simulated. During serialization, a type tag is added and saved to distinguish between persistent and non-persistent arrays. For persistent arrays, the state representation stores the actual data, ensuring that the array data can be correctly restored after persistence. For non-persistent arrays, only the allocated length is saved. During loading, non-persistent arrays are initialized to all zeros to ensure that they are correctly initialized after loading and to avoid data inconsistency issues.

[0086] When the object is a non-primitive data type and not an array, recursively process the referenced object and create its state representation.

[0087] A state list is used to track objects that have already been processed, ensuring that each object is processed only once. This avoids processing the same object repeatedly, thus improving efficiency and preventing infinite recursion. Before processing each object, it is checked whether it already exists in the object state list. If it exists, the existing state representation is used; otherwise, a new state representation is created.

[0088] In Java Card applications, complex reference relationships may exist between objects, such as cross-instance references. An object A might reference another object B, while another object C might reference yet another object B. To properly handle these reference relationships, these references need to be recorded in the object state list and re-established during recovery. This ensures effective management of cross-instance references and guarantees data consistency and integrity during persistence and recovery.

[0089] For cross-instance references, a list of instance reference relationships is established to avoid duplicate persistence. Each applet establishes a corresponding table of referenced instances, recording its AID and object ID for referencing external objects, determining the instance loading order, and resolving cross-instance reference relationships.

[0090] For example, the application instance holding a reference (such as A) does not persist the specific data of the referenced object (such as B). Instead, it persists a list of instance reference relationships to prevent the same object from being persisted multiple times in different environments, which could lead to data inconsistency. When loading reference relationships, the reference relationships of all application instances are parsed, the instance reference relationship maintenance list of all application instances is traversed, the AID and object ID of the referencing instances are extracted, a reference sort is constructed, and a topological sort is performed based on the reference relationships. The referenced instances are loaded first, followed by the instances holding the references. For example, using the AID of each instance as a node and the referenced party (instance B) pointing to the referrer (such as instance A) as an edge, a topological sort is constructed to generate the loading order. This ensures that the referenced instances are loaded before the instances holding the references, and when loading the instances holding the references, the links to the referenced objects are reconstructed based on the AID and object ID. If instance A references instance B, and then instance C references instance B, the topological sort will be as follows: .

[0091] Instances are loaded into memory in topological order, ensuring that the referenced objects already exist. Objects are deserialized from persistent files into memory, and memory addresses are allocated. The mapping between object IDs and pointers is then recorded, and the persistent reference identifier (AID + object ID) is converted into a memory pointer.

[0092] The process iterates through the object state list, maintains a list of instance references for each instance, and searches for the external objects it references. When loading an instance that holds a reference, the object is retrieved from the target instance based on the AID and object ID, the pointer is obtained from the memory mapping table of the already loaded instance, and the object ID recorded in the original instance is replaced with the actual memory address.

[0093] Data operations via memory pointers (such as modifying object state) ensure atomicity in writing to disk after reference reconstruction. Upon commit, instance states are serialized to disk in reference order. Atomicity is guaranteed using write-ahead logging or copy-on-write. If a transaction is interrupted, it is rolled back to a consistent state via the log.

[0094] Through these mechanisms, the Java Card simulator can effectively manage cross-instance references, ensuring data consistency and integrity during persistence and recovery.

[0095] 3. Update and restore the state of Applet instances

[0096] After each command response sequence (application protocol data unit exchange), the target object graph is traversed, the state of all related objects is updated, and the updated object state is saved to a memory copy.

[0097] When an applet starts a new transaction, it saves a snapshot of the current state at the beginning of the transaction. During the transaction, the state of the relevant objects is updated. When the transaction is committed, the updated state is saved to an in-memory copy; when the transaction is rolled back, it restores the state to that at the beginning of the transaction.

[0098] When an applet aborts a transaction, the applet and all classes in its package need to be restored to the object state saved in the in-memory copy. This ensures that after the transaction is aborted, the application's state can be rolled back to the state before the transaction began, maintaining data consistency. The transaction abort event is captured in the applet's transaction abort method. The previously saved object state is retrieved from the in-memory copy and restored to the current object. The object's fields are traversed, and the saved field values ​​are restored to the object. For references between objects, these references are re-established to ensure the integrity of the target object graph.

[0099] Example 4

[0100] Figure 3 This is a schematic diagram of the persistent simulation device for a Java Card simulator provided in Embodiment 4 of the present invention. Figure 3 As shown, the device includes:

[0101] The state representation module 310 is used to initialize the smart card JavaCard simulator environment if there is no serialized object state, and to traverse the target object graph from the root node of the target object graph when the Java Card simulator persists the simulation, and create state representations for each object of interest.

[0102] The maintenance list creation module 320 is used to create an object status list based on the status representation of each object to be monitored, and to create an instance reference relationship maintenance list based on the object status list;

[0103] The application instance loading module 330 is used to parse the instance reference relationship maintenance list, obtain the instance loading order, and load the application instances according to the instance loading order.

[0104] The technical solution of this invention initializes the JavaCard simulator environment if no serialized object state exists. Starting from the root node of the target object graph during Java Card simulator persistence simulation, it traverses the target object graph, creating state representations for each object of interest. Based on these representations, an object state list is created, and an instance reference relationship maintenance list is generated. This list is then parsed to determine the instance loading order, and application instances are loaded according to this order. In this solution, the object state list collects the states of processed objects, and the instance reference relationship maintenance list, generated from the application instance references in the object state list, automatically determines the instance loading order. This successfully completes persistence simulation in cross-instance reference scenarios, solving the high development complexity problem associated with manually recording states during Java Card simulator persistence simulation. It reduces the development complexity of Java Card simulator persistence simulation and accurately simulates cross-instance reference scenarios.

[0105] Optionally, the persistent simulation device of the Java Card simulator further includes a target object graph creation module, used to obtain object instances in the Java Card simulator environment; and to create the target object graph based on the object instances in the Java Card simulator environment and the reference relationships between the object instances.

[0106] Optionally, the maintenance list creation module 320 includes a maintenance list creation unit, used to determine the object reference relationship, the identifier of each application object, and the number of each application object according to the object status list; and to create an instance reference relationship maintenance list for each application object according to the object reference relationship, the identifier of each application object, and the number of each application object.

[0107] Optionally, the application instance loading module 330 includes a loading order determination unit, used to maintain a list based on the instance reference relationship, create an application instance reference topology, and determine the application instance reference order based on the application instance reference topology; and use the application instance reference order as the instance loading order.

[0108] Optionally, the application instance loading module 330 includes an instance loading unit, used to obtain the application instance memory address according to the application object number, the application object identifier and the memory mapping table; and to load the application instance according to the instance loading order and the application instance memory address.

[0109] Optionally, the persistent simulation device of the Java Card simulator further includes a state update module, used to obtain the current state of the processed object; if the currently processed object exists in the object state list, then update the object state of the currently processed object according to the current state of the processed object; if the currently processed object does not exist in the object state list, then create an object representation of the currently processed object.

[0110] Optionally, the Java Card simulator's persistence emulation device also includes a deserialization module for deserializing the target file if a serialized object state exists.

[0111] The persistent simulation device for the Java Card simulator provided in this embodiment of the invention can execute the persistent simulation method for the Java Card simulator provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0112] Example 5

[0113] Figure 4 A schematic diagram of an electronic device that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0114] like Figure 4 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as ROM 12, RAM 13, etc., communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded into the RAM 13 from the storage unit 18. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An I / O interface 15 is also connected to the bus 14. The ROM 12 is a read-only memory, the RAM 13 is a random access memory, and the I / O interface 15 is an input / output interface.

[0115] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0116] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as the persistent simulation method of a JavaCard simulator.

[0117] In some embodiments, the persistent emulation method of the Java Card simulator can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the persistent emulation method of the Java Card simulator described above can be performed. Alternatively, in other embodiments, processor 11 can be configured to execute the persistent emulation method of the Java Card simulator by any other suitable means (e.g., by means of firmware).

[0118] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0119] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0120] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, RAM, ROM, erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0121] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0122] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0123] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS servers, such as high management difficulty and weak business scalability.

[0124] This application also discloses a computer program product, which includes a computer program that, when executed by a processor, implements the persistent simulation method for the Java Card simulator provided in any embodiment of this application. This program product and the persistent simulation method for the Java Card simulator disclosed in the embodiments of this application belong to the same inventive concept, and therefore will not be described in detail here.

[0125] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0126] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A persistent simulation method for a Java Card simulator, characterized in that, include: If no serialized object state exists, the Java Card simulator environment is initialized, and the target object graph is traversed starting from the root node of the target object graph during Java Card simulator persistence simulation to create state representations for each object of interest. Based on the state representation of each object to be monitored, create an object state list, and based on the object state list, create an instance reference relationship maintenance list; The instance reference relationship maintenance list is parsed to obtain the instance loading order, and the application instances are loaded according to the instance loading order.

2. The method according to claim 1, characterized in that, Before traversing the target object graph from the root node of the Java Card simulator's persistent simulation and creating state representations for each object of interest, the process also includes: Obtain the object instance in the Java Card simulator environment; The target object graph is created based on the object instances in the Java Card simulator environment and the reference relationships between the object instances.

3. The method according to claim 1, characterized in that, Based on the object state list, create an instance reference relationship maintenance list, including: Based on the object status list, determine the object reference relationships, object identifiers, and object numbers of each application object; Based on the object reference relationships of each application object, the identifiers of each application object, and the numbers of each application object, create an instance reference relationship maintenance list for each application object.

4. The method according to claim 3, characterized in that, Parse the instance reference relationship maintenance list to obtain the instance loading order, including: Based on the instance reference relationship maintenance list, create an application instance reference topology, and determine the application instance reference order based on the application instance reference topology; The order in which the application instances are referenced will be used as the loading order of the instances.

5. The method according to claim 3, characterized in that, The application instances are loaded according to the instance loading order, including: Based on the application object number, the application object identifier, and the memory mapping table, obtain the memory address of the application instance; The application instance is loaded according to the instance loading order and the application instance memory address.

6. The method according to claim 3, characterized in that, After loading the application instances according to the instance loading order, the process also includes: Get the current state of the processed object; If the currently processed object exists in the object state list, then update the object state of the currently processed object according to its current state. If the currently processed object does not exist in the object state list, then an object representation of the currently processed object is created.

7. The method according to claim 1, characterized in that, Also includes: If a serialized object state exists, perform a deserialization operation on the target file.

8. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the persistent simulation method of the Java Card simulator according to any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the persistent simulation method of the Java Card simulator according to any one of claims 1-7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the persistent simulation method of the Java Card simulator according to any one of claims 1-7.

Images