Abnormality processing method and device for Java smart card and electronic equipment

Abstract

The invention relates to the technical field of intelligent card data processing, and discloses an exception handling method for a Java intelligent card, which comprises the following steps: constructing a full life cycle index module of a program conversion package CAP file; wherein the full life cycle index module comprises a global registry; under the condition that the Java code of the Java intelligent card is abnormal, positioning a target CAP file corresponding to the abnormal code according to a full life cycle index module; according to the target CAP file and an exception type mapping table recorded in the global registry, running a target exception information processor in an exception information processing group of the target CAP file to capture an exception code; and after the abnormal code is captured, updating the state of a global registry of the full life cycle index module according to the current state of the target CAP file. According to the method, the exception type mapping table is added, the invalid operation of traversing the processor is reduced, and the capture efficiency is improved. The invention further discloses an exception handling device for the Java smart card and electronic equipment.

Description

Exception handling methods and devices for Java smart cards, electronic devices Technical Field

[0001] This application relates to the field of smart card data processing technology, such as an exception handling method and apparatus, and electronic device for Java smart cards. Background Technology

[0002] Java smart card applications implement corresponding functions by calling API (Application Programming Interface) class data packages. These API class data packages are primarily downloaded to the Java smart card in CAP (Converted Applet Package) file format. Each CAP package contains an exception handling information group, which can be traversed to catch exceptions in the Java smart card. Traditionally, when Java code throws an exception, the exception handling information groups of all CAP packages are traversed sequentially according to their registration order in the Java card runtime environment until the exception is caught. In practice, traversing the exception handling information groups of other CAP packages delays exception catching, reducing exception catching efficiency.

[0003] To improve anomaly capture efficiency, a data processing technology for Java smart cards is disclosed, including: establishing a CAP file index record module to record the index information of CAP files; finding the corresponding CAP file based on the index information recorded in the CAP file index record module; traversing the anomaly information processing group of the CAP file and capturing the anomaly.

[0004] In the process of implementing the embodiments of this disclosure, it was found that at least the following problems exist in the related technologies: Although the related technologies do not require it, they still need to traverse the abnormal information processing group of the CAP file found according to the index information, which will still affect the capture efficiency.

[0005] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0006] To provide a basic understanding of some aspects of the disclosed embodiments, a brief summary is given below. This summary is not intended as a general commentary, nor is it intended to identify key / important components or describe the scope of protection of these embodiments, but rather as a prelude to the detailed description that follows.

[0007] This disclosure provides an exception handling method, apparatus, and electronic device for Java smart cards to improve the exception capture efficiency of Java smart cards.

[0008] In some embodiments, the exception handling method for Java smart cards includes: constructing a full lifecycle index module for CAP files; wherein the full lifecycle index module includes a global registry; when an exception occurs in the Java code of the Java smart card, locating the target CAP file corresponding to the exception code according to the full lifecycle index module; running the target exception information processor in the exception information processing group of the target CAP file to capture the exception code according to the exception type mapping table recorded in the target CAP file and the global registry; and after capturing the exception code, updating the state of the global registry of the full lifecycle index module according to the current state of the target CAP file.

[0009] Optionally, the global registry of the full lifecycle index module includes: the CAP file status field and the address range of the CAP file status field.

[0010] Optionally, in the event of an exception in the Java code of the Java smart card, the target CAP file corresponding to the exception code is located based on the full lifecycle index module, including: reading the bytecode address of the exception code recorded by the Java smart card; matching the read bytecode address with the address range of multiple CAP files in the global registry where the status field is 0; if the first bytecode address of the exception code bytecode address is in the first address range, then the CAP file corresponding to the first address range is taken as the target CAP file.

[0011] Optionally, based on the exception type mapping table recorded in the target CAP file and the global registry, the target exception information processor in the exception information processing group of the target CAP file is run to capture the exception code, including: extracting the exception type ID of the exception code; reading the exception type mapping table recorded in the global registry based on the CAP file handle of the target CAP file; matching the exception type ID with the exception type mapping table, determining and running the target exception information processor in the exception information processing group of the target CAP file to capture the exception code.

[0012] Optionally, the exception type ID is matched with the exception type mapping table, and a target exception information processor is determined and run in the exception information processing group of the target CAP file to capture the exception code. This includes: if the key-value pair in the exception type mapping table matches the exception type ID, the target exception information processor corresponding to the key-value pair is determined and run to capture the exception code; if the key-value pair in the exception type mapping table does not match the exception type ID, the general processors in the exception information processing group that are not covered by the exception type mapping table are traversed until a processor that can capture the current exception code is obtained as the target exception information processor to capture the exception code.

[0013] Optionally, if a key-value pair in the exception type mapping table matches an exception type ID, the target exception information processor corresponding to the key-value pair is determined and executed to capture the exception code, including: if a key-value pair in the exception type mapping table matches an exception type ID, obtaining the offset address of the target exception information processor corresponding to the key-value pair; jumping to the target exception information processor corresponding to the offset address to perform a capture operation to capture the exception code.

[0014] Optionally, after capturing the exception code, the state of the global registry of the full lifecycle index module is updated according to the current state of the target CAP file, including: after capturing the exception code, querying the global registry corresponding to the target CAP file to obtain the CAP file status field of the target CAP file; if the CAP file status field of the target CAP file is 1, querying the stack frame and handle associated with the target CAP file; if no stack frame and handle are found, updating the CAP file status field of the target CAP file in the global registry to 2.

[0015] In some embodiments, the exception handling apparatus for a Java smart card includes: a construction module configured to construct a full lifecycle index module for a program conversion package (CAP) file; wherein the full lifecycle index module includes a global registry; a location module configured to locate the target CAP file corresponding to the exception code based on the full lifecycle index module when an exception occurs in the Java code of the Java smart card; a capture module configured to run the target exception information processor in the exception information processing group of the target CAP file to capture the exception code based on the exception type mapping table recorded in the global registry; and an update module configured to update the state of the global registry of the full lifecycle index module according to the current state of the target CAP file after capturing the exception code.

[0016] In some embodiments, the exception handling apparatus for a Java smart card includes a processor and a memory storing program instructions, the processor being configured to execute the exception handling method for a Java smart card as described above when the program instructions are executed.

[0017] In some embodiments, the electronic device includes: an electronic device body; and an exception handling device for a Java smart card, as described above, installed on the electronic device body.

[0018] The exception handling method, apparatus, and electronic device for Java smart cards provided in this disclosure can achieve the following technical effects: In this disclosure, an exception type mapping table is added to the exception information processing group of the CAP file, directly associating the exception type with the corresponding target exception information; when an exception occurs, the target exception information processor can be located through the exception type mapping table, without having to traverse the entire exception information processing group one by one. Using the exception type mapping table can effectively shield all processors unrelated to the current exception, eliminating a large number of invalid operations such as matching and jumping, significantly shortening the capture latency, and improving exception capture efficiency.

[0019] The above general description and the description below are exemplary and illustrative only and are not intended to limit this application. Attached Figure Description

[0020] One or more embodiments are illustrated by way of example with reference to the accompanying drawings. These illustrations and drawings do not constitute a limitation on the embodiments. Elements having the same reference numerals in the drawings are shown as similar elements. The drawings are not to be scaled. Figure 1 is a schematic diagram of an exception handling method for a Java smart card provided by an embodiment of the present disclosure; Figure 2 is a schematic diagram of another exception handling method for a Java smart card provided by an embodiment of the present disclosure; Figure 3 is a schematic diagram of another exception handling method for a Java smart card provided by an embodiment of the present disclosure; Figure 4 is a schematic diagram of another exception handling method for a Java smart card provided by an embodiment of the present disclosure; Figure 5 is a schematic diagram of an exception handling device for a Java smart card provided by an embodiment of the present disclosure; Figure 6 is a schematic diagram of another exception handling device for a Java smart card provided by an embodiment of the present disclosure. Detailed Implementation

[0021] To provide a more detailed understanding of the features and technical content of the embodiments of this disclosure, the implementation of the embodiments of this disclosure will be described in detail below with reference to the accompanying drawings. The accompanying drawings are for illustrative purposes only and are not intended to limit the embodiments of this disclosure. In the following technical description, for ease of explanation, several details are used to provide a full understanding of the disclosed embodiments. However, one or more embodiments may still be implemented without these details. In other cases, well-known structures and devices may be simplified in their depiction to simplify the drawings.

[0022] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure 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 for the embodiments of this disclosure described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion.

[0023] Unless otherwise stated, the term "multiple" means two or more.

[0024] In this embodiment of the disclosure, the character " / " indicates that the objects before and after it are in an "or" relationship. For example, A / B means: A or B.

[0025] The term "and / or" describes an association between objects, indicating that three relationships can exist. For example, A and / or B means: A or B, or A and B.

[0026] The term "correspondence" can refer to an association or binding relationship. The correspondence between A and B means that there is an association or binding relationship between A and B.

[0027] Currently, Java, as a relatively mature programming language, is widely used in various program programming. With the increasing popularity and rapid development of computers, people are placing increasingly higher demands on the functionality of applications. Along with the improvement and enhancement of functionality, the complexity of programs also increases, leading to a decrease in program stability and reliability, and causing various abnormal situations to occur during program execution. To track and find the exact location of program exceptions, various methods for catching program exceptions have been developed. In practical applications, exception catching requires traversing the exception handling information groups in the CAP theorem, which reduces the efficiency of exception catching.

[0028] Referring to Figure 1, this embodiment of the present disclosure provides an exception handling method for Java smart cards, including: S101, constructing a full lifecycle index module for the program conversion package CAP file; wherein, the full lifecycle index module includes a global registry.

[0029] S102, in the event of an exception in the Java code of the Java smart card, locate the target CAP file corresponding to the exception code based on the full lifecycle index module.

[0030] S103, based on the exception type mapping table recorded in the target CAP file and the global registry, run the target exception information processor in the exception information processing group of the target CAP file to capture the exception code.

[0031] S104. After capturing the exception code, update the state of the global registry of the full lifecycle index module according to the current state of the target CAP file.

[0032] The method provided in this disclosure adds an exception type mapping table to the exception information processing group of the CAP file, directly associating exception types with their corresponding processors. When an exception occurs, the target exception information processor can be located through the exception type mapping table, eliminating the need to traverse the entire exception information processing group line by line. The exception type mapping table effectively masks all processors unrelated to the current exception, eliminating numerous invalid operations such as matching and jumping, significantly shortening capture latency, and improving exception capture efficiency.

[0033] Optionally, the global registry of the full lifecycle index module includes: the CAP file status field and the address range of the CAP file status field.

[0034] In this embodiment, the global registry records the CAP file status field and address range, enabling the virtual machine to determine which code space is active and can be matched abnormally without parsing the entire card directory; after the status field and address range are bound, any address query becomes a range comparison, directly filtering out CAP areas that have been unloaded, not loaded, or are being garbage collected, thus avoiding invalid searches.

[0035] The CAP file status field provides a basis for locating valid CAP files and updating the registry status; the clearly defined address range field provides a precise data carrier for matching the bytecode addresses of exception codes. The combination of these two features allows the global registry to avoid invalid data occupying the limited storage of the smart card, while simultaneously laying a data foundation for the efficient execution of subsequent steps.

[0036] Optionally, in the event of an exception in the Java code of the Java smart card, the target CAP file corresponding to the exception code is located based on the full lifecycle index module, including: reading the bytecode address of the exception code recorded by the Java smart card; matching the read bytecode address with the address range of multiple CAP files in the global registry where the status field is 0; if the first bytecode address of the exception code bytecode address is in the first address range, then the CAP file corresponding to the first address range is taken as the target CAP file.

[0037] Referring to Figure 2, this disclosure provides another exception handling method for Java smart cards, including: S201, constructing a full lifecycle index module for the program conversion package CAP file; wherein, the full lifecycle index module includes a global registry.

[0038] S202, read the bytecode address of the exception code recorded by the Java smart card.

[0039] S203, match the read bytecode address with the address range of multiple CAP file status fields in the global registry that are 0.

[0040] S204. If the first bytecode address of the exception code bytecode address is within the first address range, then the CAP file corresponding to the first address range will be used as the target CAP file.

[0041] S205, based on the exception type mapping table recorded in the target CAP file and the global registry, run the target exception information processor in the exception information processing group of the target CAP file to capture the exception code.

[0042] S206, after capturing the exception code, update the state of the global registry of the full lifecycle index module according to the current state of the target CAP file.

[0043] Upon exception triggering, the Java Smart Card Virtual Machine reads the current bytecode address and the first bytecode address of the exception code segment through atomic operations. Atomic operations ensure the integrity of address reading, preventing address corruption in multi-threaded concurrent scenarios, and the entire reading process is extremely fast. Next, it filters active and matchable program conversion package file entries from the global registry, forming a valid file set. Each entry includes not only the start and end addresses but also an address checksum calculated using a cyclic redundancy check algorithm to verify whether the address range has been tampered with, ensuring address validity. Then, a two-stage address matching process is initiated. The first stage determines whether the current bytecode address falls within the address range of a program conversion package file, while verifying address integrity. If a unique matching file exists, it is directly identified as the target file. If multiple file address ranges overlap, the second stage begins, filtering based on the distance threshold between the first bytecode address and the start address of the program conversion package file, prioritizing files with smaller address ranges to improve matching accuracy and avoid cross-file mislocation. This matching process is highly efficient. Even in the worst-case scenario where the number of program conversion package files active in the smart card is limited, the matching can be completed in a very short time. The address matching accuracy is extremely high, and it can accurately locate the target file corresponding to the abnormal code.

[0044] In this embodiment, entries with a CAP file status field of 0 in the global registry are prioritized for filtering, directly excluding invalid CAP files that are to be uninstalled or have already been uninstalled, thus reducing the number of traversals. Simultaneously, address matching of the first bytecode is performed to avoid redundant matching when multiple CAP file addresses overlap, further shortening the location time. This solution can significantly reduce the latency of anomaly location and ensure the real-time performance of Java smart card applications.

[0045] Optionally, based on the exception type mapping table recorded in the target CAP file and the global registry, the target exception information processor in the exception information processing group of the target CAP file is run to capture the exception code, including: extracting the exception type ID of the exception code; reading the exception type mapping table recorded in the global registry based on the CAP file handle of the target CAP file; matching the exception type ID with the exception type mapping table, determining and running the target exception information processor in the exception information processing group of the target CAP file to capture the exception code.

[0046] Referring to Figure 3, this disclosure provides another exception handling method for Java smart cards, including: S301, constructing a full lifecycle index module for the program conversion package CAP file; wherein, the full lifecycle index module includes a global registry.

[0047] S302, in the event of an exception in the Java code of a Java smart card, locate the target CAP file corresponding to the exception code based on the full lifecycle index module.

[0048] S303, Extract the exception type ID of the exception code.

[0049] S304, based on the CAP file handle of the target CAP file, read the exception type mapping table recorded in the global registry.

[0050] S305, match the exception type ID with the exception type mapping table, identify and run the target exception information processor in the exception information processing group of the target CAP file to capture the exception code.

[0051] S306, after capturing the exception code, updates the state of the global registry of the full lifecycle index module according to the current state of the target CAP file.

[0052] In this embodiment, an exception type mapping table is introduced, directly associating exception types with target exception information processors. When an exception occurs, the exception type ID is extracted first, and then the mapping table is read from the target CAP file. This eliminates the need to traverse the entire exception handling information group to match the target exception information processor, reducing unnecessary traversal operations and lowering the computing power consumption of the Java smart card. Simultaneously, the mapping table address is stored in the global registry, avoiding lookup confusion caused by data dispersion and further improving the stability and efficiency of exception capture.

[0053] Optionally, the exception type ID is matched with the exception type mapping table, and a target exception information processor is determined and run in the exception information processing group of the target CAP file to capture the exception code. This includes: if the key-value pair in the exception type mapping table matches the exception type ID, the target exception information processor corresponding to the key-value pair is determined and run to capture the exception code; if the key-value pair in the exception type mapping table does not match the exception type ID, the general processors in the exception information processing group that are not covered by the exception type mapping table are traversed until a processor that can capture the current exception code is obtained as the target exception information processor to capture the exception code.

[0054] Once the exception type identifier successfully matches a key-value pair in the exception type mapping table, the relative offset address of the target exception information processor is extracted from the mapping table. This address, in bytes, is offset relative to the base address of the target program conversion package file. To ensure the validity of the offset address, double verification is performed: first, it checks whether the offset address is within the length range of the exception information processing group in the target program conversion package file; second, it verifies whether the address meets the alignment requirements to avoid invalid address access. Subsequently, the physical address of the target exception information processor is obtained by combining the base address of the target program conversion package file with a dynamically calculated address correction value. The base address is quickly obtained by the smart card virtual machine through the program conversion package file handle, and the address correction value is dynamically adjusted according to the actual storage situation of the smart card to ensure accurate address mapping. During jump execution, a direct address jump instruction is used, skipping redundant operations such as stack frame creation and parameter pushing required by traditional function calls, significantly reducing jump time. To ensure the atomicity of the jump, a memory barrier instruction is executed before the jump to ensure that the address read and calculation results are synchronized to memory, avoiding jump errors caused by instruction reordering. Simultaneously, an exception rollback mechanism is implemented. If an exception is not captured within a specified time after the jump, a rollback instruction will be triggered, and the exception type matching process will be re-executed to ensure the reliability of capture. In addition, the offset address uses dual backup storage. When the address verification of the primary storage fails, the backup address is automatically read, and the physical address is verified for integrity through an error correction verification algorithm, effectively avoiding data errors during address transmission and further improving the jump success rate.

[0055] In this embodiment, when a match is successful, the corresponding target exception information processor is directly invoked, skipping redundant traversal and maximizing efficiency. When a match fails, only general processors not covered by the mapping table, such as finally processors and general exception processors, are traversed, rather than the entire exception handling information group, reducing unnecessary computational power consumption. This avoids the risk of missed exceptions caused by relying solely on the exception type mapping table while retaining its high efficiency advantages, thus balancing the efficiency and reliability of Java smart card exception handling.

[0056] Optionally, if a key-value pair in the exception type mapping table matches an exception type ID, the target exception information processor corresponding to the key-value pair is determined and executed to capture the exception code, including: if a key-value pair in the exception type mapping table matches an exception type ID, obtaining the offset address of the target exception information processor corresponding to the key-value pair; jumping to the target exception information processor corresponding to the offset address to perform a capture operation to capture the exception code.

[0057] Once the key-value match is successful, the processor offset address is obtained immediately and the jump is performed directly without the need for function table lookup and parameter pushing. The offset address can be relocated during CAP loading, and there is no need to resolve the symbol again at runtime.

[0058] In this embodiment, after the exception type ID matches the exception type mapping table, the offset address of the target processor is directly obtained without needing to search for the location of the exception handling information group a second time. This address jump further reduces latency.

[0059] Optionally, after capturing the exception code, the state of the global registry of the full lifecycle index module is updated according to the current state of the target CAP file, including: after capturing the exception code, querying the global registry corresponding to the target CAP file to obtain the CAP file status field of the target CAP file; if the CAP file status field of the target CAP file is 1, querying the stack frame and handle associated with the target CAP file; if no stack frame and handle are found, updating the CAP file status field of the target CAP file in the global registry to 2.

[0060] Referring to Figure 4, this disclosure provides another exception handling method for Java smart cards, including: S401, constructing a full lifecycle index module for the program conversion package CAP file; wherein, the full lifecycle index module includes a global registry.

[0061] S402, in the event of an exception in the Java code of a Java smart card, locate the target CAP file corresponding to the exception code based on the full lifecycle index module.

[0062] S403, based on the exception type mapping table recorded in the target CAP file and the global registry, run the target exception information processor in the exception information processing group of the target CAP file to capture the exception code.

[0063] S404: After capturing the exception code, query the global registry corresponding to the target CAP file to obtain the CAP file status field of the target CAP file.

[0064] S405, if the CAP file status field of the target CAP file is 1, query the stack frame and handle associated with the target CAP file.

[0065] S406, If no stack frame and handle are found, update the CAP file status field of the target CAP file in the global registry to 2.

[0066] After exception capture, the global registry is queried using the unique identifier of the target program conversion package file to obtain its status field. The status field is divided into three categories: active and matchable, pending uninstallation and locked, and uninstalled and invalid. The query process uses a binary search algorithm to quickly locate the registry entry, which is time-efficient and efficient. At the same time, the validity of the status field is verified to avoid misjudgment of the status due to storage corruption. If the status is active and matchable, the status remains unchanged, and only the last access timestamp of the registry entry is updated to provide data support for subsequent garbage collection strategies. If the status is pending uninstallation and locked, the associated resource query process is initiated. When querying stack frames, the thread control block of the smart card virtual machine is traversed to count the number of active stack frames associated with the target program conversion package file. A batch query mechanism is used to improve query efficiency, and the statistics can be completed quickly in scenarios with a limited number of active threads. When querying handles, the handle linked list of the handle management module is traversed to count the number of valid handles associated with the target program conversion package file. The handle linked list uses a hash table index to quickly locate the associated handles, shortening the query time. When both the number of active stack frames and the number of valid handles are zero, a compare-and-swap atomic operation is used to update the state to "unloaded and invalid," ensuring the atomicity of the state update and avoiding conflicts caused by concurrent modifications by multiple threads. If the atomic operation fails, a retry mechanism is initiated, with a limited number of retries and extremely short intervals between each retry. If the retry still fails, a global lock is triggered to enforce the uniqueness of the state update. After the state is updated to "unloaded and invalid," the registry entry is marked as recyclable, and subsequently cleaned up in batches by the garbage collection thread, releasing the storage and handle resources occupied by the target program's conversion package file. This ensures that the global registry always maintains a valid data state, improving the long-term stability of the system.

[0067] In this embodiment, after an exception is captured, the status field of the target CAP file is first queried. If it is 1 (status 1 is a pending unloading locked state), the associated stack frame and handle are checked. After confirming that no method is being executed, the status is updated to 2 (status is an unloaded and invalid state). Through status updates, global registry entries with status 2 can be periodically cleaned up to release storage resources and ensure that methods being executed in the Java smart card are not affected. This ensures that the global registry always maintains a state of "valid data," improving the long-term stability of the system.

[0068] Referring to Figure 5, this embodiment of the present disclosure provides an exception handling device 500 for Java smart cards, including a construction module 501, a location module 502, a capture module 503, and an update module 504. The construction module 501 is configured to build a full lifecycle index module for program conversion package (CAP) files; wherein, the full lifecycle index module includes a global registry; the location module 502 is configured to locate the target CAP file corresponding to the exception code based on the full lifecycle index module when an exception occurs in the Java code of the Java smart card; the capture module 503 is configured to run the target exception information processor in the exception information processing group of the target CAP file to capture the exception code based on the exception type mapping table recorded in the global registry; the update module 504 is configured to update the state of the global registry of the full lifecycle index module according to the current state of the target CAP file after capturing the exception code.

[0069] Using the apparatus 500 provided in this embodiment, an exception type mapping table is added to the exception information processing group of the CAP file, directly associating exception types with corresponding target exception information. When an exception occurs, the capture module 503 can determine the target exception information processor through the exception type mapping table, without having to traverse the entire exception information processing group line by line. The exception type mapping table effectively masks all processors unrelated to the current exception, eliminating numerous invalid operations such as matching and jumping, significantly shortening the capture delay, and improving exception capture efficiency.

[0070] Referring to Figure 6, this embodiment of the present disclosure provides an exception handling device 70 for Java smart cards, including a processor 600 and a memory 601. Optionally, the device 60 may further include a communication interface 602 and a bus 603. The processor 600, communication interface 602, and memory 601 can communicate with each other via the bus 603. The communication interface 602 can be used for information transmission. The processor 600 can call logical instructions in the memory 601 to execute the exception handling method for Java smart cards described in the above embodiment.

[0071] Furthermore, the logic instructions in the aforementioned memory 601 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium.

[0072] The memory 601, as a computer-readable storage medium, can be used to store software programs and computer-executable programs, such as program instructions / modules corresponding to the methods in the embodiments of this disclosure. The processor 600 executes functional applications and data processing by running the program instructions / modules stored in the memory 601, thereby implementing the exception handling method for Java smart cards described in the above embodiments.

[0073] The memory 601 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the terminal device. Furthermore, the memory 601 may include high-speed random access memory and may also include non-volatile memory.

[0074] This disclosure provides an electronic device, including: an electronic device body, and the aforementioned exception handling device for Java smart cards. The exception handling device for Java smart cards is installed in the electronic device body. The installation relationship described herein is not limited to placement within the electronic device body, but also includes installation connections with other components of the electronic device, including but not limited to physical connections, electrical connections, or signal transmission connections. Those skilled in the art will understand that the exception handling device for Java smart cards can be adapted to feasible electronic device bodies to achieve other feasible embodiments.

[0075] The technical solutions of this disclosure can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes one or more instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in this disclosure. The aforementioned storage medium can be a non-transitory storage medium, such as a USB flash drive, external hard drive, read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk, etc., and other media capable of storing program code.

[0076] The foregoing description and accompanying drawings fully illustrate embodiments of this disclosure to enable those skilled in the art to practice them. Other embodiments may include structural, logical, electrical, procedural, and other changes. The embodiments represent only possible variations. Individual components and functions are optional unless explicitly required, and the order of operation may vary. Parts and features of some embodiments may be included in or replace parts and features of other embodiments. Moreover, the terminology used in this application is for describing embodiments only and is not intended to limit the claims. As used in the description of embodiments and claims, the singular forms “a,” “an,” and “the” are intended to equally include the plural forms unless the context clearly indicates otherwise. Similarly, the term “and / or” as used in this application means including one or more of the associated listed items and all possible combinations thereof. Additionally, when used in this application, the term "comprise" and its variations "comprises" and / or "comprising" refer to the presence of stated features, integrals, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof. Without further limitations, an element defined by the phrase "comprises a..." does not exclude the presence of other identical elements in the process, method, or apparatus that includes said element. In this document, each embodiment may focus on the differences from other embodiments, and similar or identical parts between embodiments can be referred to mutually. For methods, products, etc., disclosed in the embodiments, if they correspond to the method section disclosed in the embodiments, the relevant parts can be referred to the description of the method section.

[0077] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of this disclosure. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0078] The methods and products disclosed in the embodiments herein (including but not limited to devices and equipment) can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For instance, the division of units may be merely a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to implement this embodiment according to actual needs. In addition, the functional units in the embodiments of this disclosure may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0079] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than that shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. In the descriptions corresponding to the flowcharts and block diagrams in the accompanying drawings, the operations or steps corresponding to different blocks may also occur in a different order than disclosed in the description, and sometimes there is no specific order between different operations or steps. For example, two consecutive operations or steps may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. Each block in a block diagram and / or flowchart, and combinations of blocks in a block diagram and / or flowchart, 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.

Claims

1. An exception handling method for Java smart cards, characterized in that, include: A full lifecycle index module for the program conversion package CAP file is constructed; the full lifecycle index module includes a global registry; in the event of an exception in the Java code of the Java smart card, the target CAP file corresponding to the exception code is located according to the full lifecycle index module; based on the exception type mapping table recorded in the target CAP file and the global registry, the target exception information processor in the exception information processing group of the target CAP file is run to capture the exception code; after capturing the exception code, the state of the global registry of the full lifecycle index module is updated according to the current state of the target CAP file.

2. The anomaly handling method according to claim 1, characterized in that, The global registry of the full lifecycle index module includes: the CAP file status field and the address range of the CAP file status field.

3. The anomaly handling method according to claim 2, characterized in that, In the event of an exception in the Java code of a Java smart card, the target CAP file corresponding to the exception code is located based on the full lifecycle index module. This includes: reading the bytecode address of the exception code recorded by the Java smart card; matching the read bytecode address with the address range of multiple CAP files in the global registry where the status field is 0; if the first bytecode address of the exception code bytecode address is within the first address range, then the CAP file corresponding to the first address range is taken as the target CAP file.

4. The anomaly handling method according to claim 1, characterized in that, Based on the exception type mapping table recorded in the target CAP file and the global registry, the target exception information processor in the exception information processing group of the target CAP file is run to capture the exception code, including: extracting the exception type ID of the exception code; reading the exception type mapping table recorded in the global registry based on the CAP file handle of the target CAP file; matching the exception type ID with the exception type mapping table, determining and running the target exception information processor in the exception information processing group of the target CAP file to capture the exception code.

5. The anomaly handling method according to claim 4, characterized in that, The exception type ID is matched with the exception type mapping table. The target exception information processor is determined and run in the exception information processing group of the target CAP file to capture the exception code. This includes: if the key-value pair in the exception type mapping table matches the exception type ID, the target exception information processor corresponding to the key-value pair is determined and run to capture the exception code; if the key-value pair in the exception type mapping table does not match the exception type ID, the general processors in the exception information processing group that are not covered by the exception type mapping table are traversed until a processor that can capture the current exception code is obtained as the target exception information processor to capture the exception code.

6. The anomaly handling method according to claim 5, characterized in that, If a key-value pair in the exception type mapping table matches an exception type ID, determine and run the target exception information processor corresponding to the key-value pair to capture the exception code, including: if a key-value pair in the exception type mapping table matches an exception type ID, obtain the offset address of the target exception information processor corresponding to the key-value pair; jump to the target exception information processor corresponding to the offset address to perform a capture operation to capture the exception code.

7. The anomaly handling method according to any one of claims 1 to 6, characterized in that, After capturing the exception code, the global registry of the full lifecycle index module is updated according to the current state of the target CAP file. This includes: querying the global registry corresponding to the target CAP file after capturing the exception code to obtain the CAP file status field of the target CAP file; if the CAP file status field of the target CAP file is 1, querying the stack frame and handle associated with the target CAP file; if no stack frame and handle are found, updating the CAP file status field of the target CAP file in the global registry to 2.

8. An exception handling device for Java smart cards, characterized in that, include: The build module is configured to build a full lifecycle index module for the CAP file of the program conversion package; the full lifecycle index module includes a global registry; the location module is configured to locate the target CAP file corresponding to the exception code based on the full lifecycle index module when an exception occurs in the Java code of the Java smart card; the capture module is configured to run the target exception information processor in the exception information processing group of the target CAP file to capture the exception code based on the exception type mapping table recorded in the global registry and the target CAP file. The update module is configured to update the state of the global registry of the full lifecycle index module based on the current state of the target CAP file after an exception code is caught.

9. An exception handling apparatus for a Java smart card, comprising a processor and a memory storing program instructions, characterized in that, The processor is configured to execute the exception handling method for Java smart cards as described in any one of claims 1 to 7 when running the program instructions.

10. An electronic device, characterized in that, include: The electronic device body; the exception handling device for Java smart cards as described in claim 8 or 9, installed on the electronic device body.

Images