Java custom class loader-based judicial system modular hot loading method

Abstract

The invention discloses a judicial system modular hot loading method based on a Java custom class loader, which belongs to the technical field of computers, and comprises the following steps: designing a custom class loader, developing a custom class loader which can identify classes in a specific namespace and load the classes from a specified position; according to the modular design, the judicial information system is divided into a plurality of independent modules, and each module is responsible for a part of business logic; version control: distributing a version number for each module to facilitate the upgrade and rollback of the management module; a hot updating mechanism is adopted, when a new version module is deployed, the user-defined class loader can detect version changes and unload classes of an old version, the Java user-defined class loader mechanism is utilized, hot loading of the judicial system module is achieved, and therefore the purpose of dynamic updating is achieved, by constructing a hierarchical class loader system, the dynamic updating efficiency of the judicial system module is improved, and the dynamic updating efficiency of the judicial system module is improved. A new module version can be identified and loaded, an old version can be unloaded, and stable operation of the system is ensured.

Description

Technical Field

[0001] The invention belongs to the field of computer technology, and in particular relates to a modular hot loading method of a judicial system based on a Java custom class loader. Background Art

[0002] At present, most judicial information systems adopt the traditional deployment method, that is, when the system needs to be upgraded, it is necessary to stop the service, replace the package and restart the service. This method has the following problems: downtime: each update requires downtime, which affects the availability of the system; data consistency: data consistency problems may occur during the update process; operation complexity: manual data backup is required, and data recovery and other operations are required after the update.

[0003] The prior art discloses some invention patents in the field of computer technology, among which the invention patent with publication number CN112764827B discloses a Java class hot loading method with security verification, including the steps of: presetting a special package path for Java Web container hot loading class; encrypting Java class files to obtain ciphertext files, and publishing them in a special package path or a sub-package path directory of the special package path; detecting and judging the package path of the class before the Java class is loaded; detecting the timestamp of the ciphertext file being modified according to the located ciphertext file; decrypting and verifying the ciphertext file using Java's JNI localization method; using a Java custom class loader to load the decrypted bytecode and define the loaded class, and calling the corresponding service; releasing the memory space of the class loader. This technical solution prevents the risk of Java classes being illegally replaced in the process of supporting Java class hot loading applications, and can be effectively used in the production process of the system. However, this technical solution still has some shortcomings in the process of application. Each update must be shut down, which seriously affects the user experience and service continuity. The risk of data loss or damage may increase during the downtime, and the demand for manual intervention is high, which increases the maintenance cost.

[0004] Based on this, the present invention designs a modular hot loading method for the judicial system based on a Java custom class loader to solve the above problems. Summary of the invention

[0005] The purpose of the present invention is to solve the problems that the existing judicial system modular hot loading method still has some shortcomings in its application process, each update requires shutdown, which seriously affects the user experience and service continuity, and the risk of data loss or damage may increase during the downtime. The demand for manual intervention is high, which increases the maintenance cost. A judicial system modular hot loading method based on a Java custom class loader is proposed.

[0006] In order to achieve the above object, the present invention adopts the following technical solutions:

[0007] A modular hot loading method for a judicial system based on a Java custom class loader, comprising:

[0008] Custom class loader design, develop a custom class loader that can identify classes within a specific namespace and load these classes from a specified location;

[0009] Modular design divides the judicial information system into multiple independent modules, each of which is responsible for a part of the business logic;

[0010] Version control, assigning version numbers to each module to facilitate management of module upgrades and rollbacks;

[0011] Hot update mechanism: when a new version of a module is deployed, the custom class loader detects the version change, unloads the old version of the class, and loads the new version of the class.

[0012] As a further description of the above technical solution:

[0013] The custom class loader is designed in Java and is implemented by inheriting the ClassLoader class. The class loader overrides the findClass method to load the bytecode of the class from the specified path. The loadClass method can be optionally overridden to control the class loading process.

[0014] As a further description of the above technical solution:

[0015] A mechanism for monitoring module file changes is added to the custom class loader by periodically checking the timestamp of the module file or the file system listener.

[0016] As a further description of the above technical solution:

[0017] The Agent can dynamically modify Java bytecode, allowing developers to dynamically insert functions without modifying the target application source code. The functions include performance analysis, logging, code coverage testing and hot update. Through the Agent, developers can monitor and analyze the Java virtual machine and even intervene in the operation of the virtual machine.

[0018] As a further description of the above technical solution:

[0019] The Java class bytecode file detection includes the following contents:

[0020] By searching the device virtual machine process and selecting the specified process;

[0021] Then inject the Agent into the specified virtual machine process to traverse the Class, find the high-risk class and dump the bytecode in the memory to the local computer;

[0022] Finally, the YARA engine, which creates malware families based on binary patterns, is introduced to determine and summarize the bytecode matches stored locally.

[0023] As a further description of the above technical solution:

[0024] The Java class bytecode file detection is completed by a Java process scanning module, a Java process injection module, an Agent extraction module, a YARA rule loading module, a rule matching module, and a report generation module;

[0025] The Java process scanning module is used to scan the Java process running in the current system to obtain the PID and memory information of the Java process. The Java process injection module is used to inject the Agent into the specified Java. The Agent extraction module is used to perform Dupm of high-risk classes in the Class traversal stage.

[0026] As a further description of the above technical solution:

[0027] The YARA rule loading module is used to compile the rules in the rule file into useful rule objects while loading the YARA rule file. The rule matching module is used to match the memory information with the UAR rules to determine whether the bytecode file of the Java class has been replaced or tampered with. The report generation module is used to generate a detection report, which includes the detection results, replacement or tampering information and malicious code.

[0028] As a further description of the above technical solution:

[0029] The Java memory model allows a custom class loader to change the execution order of code during an upgrade. The Java memory model specifies how a Java virtual machine manages memory, including how to store and access object fields and methods and how to ensure data correctness and consistency in a multi-threaded environment. The Java memory model divides memory into several different areas, including a method area, a heap area, and a stack area. Each area has its specific purpose and management method.

[0030] As a further description of the above technical solution:

[0031] The Java class loading mechanism is an important manifestation of the dynamic nature of the Java language. The class loader is a component responsible for loading classes. It is used to load the bytecode file of the class into the memory and convert it into a class object recognized by the Java virtual machine. The Java class loading mechanism follows the parent delegation model. When a class loader needs to load a class, it will first try to delegate its parent class loader to load the class. Only when the parent class loader cannot load the class will it try to load it itself.

[0032] As a further description of the above technical solution:

[0033] The possibility of changing the order in which the code is executed;

[0034] In the loading phase, the custom class loader changes the source of the class and loads the bytecode file of the class from the network or a specific path;

[0035] Verification, preparation, and parsing phases, which are automatically completed by the virtual machine and are mainly responsible for verifying the correctness of the class, allocating memory for class variables and setting default values, and converting symbolic references to direct references. Custom class loaders have limited effects in these phases and usually do not change the execution order of the code;

[0036] Initialization phase: During the initialization phase, the virtual machine executes the initialization operations of the static code blocks and static variables of the class. The custom class loader indirectly affects the execution order of these operations by changing the bytecode of the class. The custom class loader modifies the initialization order of the static code blocks or static variables of the class when loading the class. These modifications will be reflected in the class initialization process.

[0037] In summary, due to the adoption of the above technical solution, the beneficial effects of the present invention are:

[0038] 1. In the present invention, the Java custom class loader mechanism is used to realize hot loading of the judicial system module, thereby achieving the purpose of dynamic updating. By constructing a hierarchical class loader system, it is possible to identify and load new module versions and uninstall old versions at the same time to ensure the stable operation of the system.

[0039] 2. In the present invention, dynamic class loading and unloading realizes dynamic loading and unloading of classes, improves the flexibility of the system, and provides imperceptible upgrades. Users will not be aware of the occurrence of upgrades while using the system. Data consistency is guaranteed through a transaction processing mechanism.

[0040] 3. In the present invention, the system availability is improved, the service interruption time caused by updates is reduced, the maintenance cost is reduced, the need for manual intervention is reduced, the degree of automation is higher, the security is enhanced, and the security and stability of the system are improved through strict version control and transaction processing.

[0041] 4. In the present invention, by injecting Agent into the virtual machine to export high-risk classes and realizing detection and location of malicious code in Java memory through YARA, Java error information is effectively detected with high detection accuracy and low false alarm rate. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Figure 1 A basic flow chart of a modular hot loading method for a judicial system based on a Java custom class loader proposed by the present invention;

[0043] Figure 2 A basic architecture diagram of a modular hot loading method for a judicial system based on a Java custom class loader proposed by the present invention;

[0044] Figure 3 A detection flow chart of a modular hot loading method for a judicial system based on a Java custom class loader proposed by the present invention;

[0045] Figure 4 This is a Java class bytecode file detection flow chart of a modular hot loading method for a judicial system based on a Java custom class loader proposed by the present invention. DETAILED DESCRIPTION

[0046] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0047] Please see attached Figure 1 -Attached Figure 4 The present invention provides a technical solution: a modular hot loading method for a judicial system based on a Java custom class loader, comprising:

[0048] Custom class loader design, develop a custom class loader that can identify classes within a specific namespace and load these classes from a specified location;

[0049] Modular design divides the judicial information system into multiple independent modules, each of which is responsible for a part of the business logic;

[0050] Version control, assigning version numbers to each module to facilitate management of module upgrades and rollbacks;

[0051] Hot update mechanism: when a new version of a module is deployed, the custom class loader detects the version change, unloads the old version of the class, and loads the new version of the class.

[0052] Specifically, the custom class loader is designed in Java and is implemented by inheriting the ClassLoader class. The class loader overrides the findClass method to load the bytecode of the class from the specified path. The loadClass method can be optionally overridden to control the class loading process.

[0053] Specifically, a mechanism for monitoring module file changes is added to the custom class loader by periodically checking the timestamp of the module file or the file system listener.

[0054] Specifically, the Agent can dynamically modify Java bytecode, allowing developers to dynamically insert functions without modifying the target application source code. The functions include performance analysis, logging, code coverage testing and hot updates. Through the Agent, developers can monitor and analyze the Java virtual machine and even intervene in the operation of the virtual machine.

[0055] Specifically, the Java class bytecode file detection includes the following contents:

[0056] By searching the device virtual machine process and selecting the specified process;

[0057] Then inject the Agent into the specified virtual machine process to traverse the Class, find the high-risk class and dump the bytecode in the memory to the local computer;

[0058] Finally, the YARA engine, which creates malware families based on binary patterns, is introduced to determine and summarize the bytecode matches stored locally.

[0059] Specifically, the Java class bytecode file detection is completed by a Java process scanning module, a Java process injection module, an Agent extraction module, a YARA rule loading module, a rule matching module, and a report generation module;

[0060] The Java process scanning module is used to scan the Java process running in the current system to obtain the PID and memory information of the Java process. The Java process injection module is used to inject the Agent into the specified Java. The Agent extraction module is used to perform Dupm of high-risk classes in the Class traversal stage.

[0061] Specifically, the YARA rule loading module is used to compile the rules in the rule file into useful rule objects while loading the YARA rule file. The rule matching module is used to match the memory information with the UAR rules to determine whether the bytecode file of the Java class has been replaced or tampered with. The report generation module is used to generate a detection report, which includes the detection results, replacement or tampering information, and malicious code.

[0062] Specifically, the Java memory model allows a custom class loader to change the execution order of the code during the upgrade process. The Java memory model specifies how the Java virtual machine manages memory, including how to store and access object fields and methods and how to ensure the correctness and consistency of data in a multi-threaded environment. The Java memory model divides the memory into several different areas, including the method area, the heap area, and the stack area. Each area has its specific purpose and management method.

[0063] Specifically, the Java class loading mechanism is an important manifestation of the dynamic nature of the Java language. The class loader is a component responsible for loading classes. It is used to load the bytecode file of the class into the memory and convert it into a class object recognized by the Java virtual machine. The Java class loading mechanism follows the parent delegation model. When a class loader needs to load a class, it will first try to delegate its parent class loader to load the class. Only when the parent class loader cannot load it will it try to load it itself.

[0064] Specifically, the possibility of changing the order of code execution;

[0065] In the loading phase, the custom class loader changes the source of the class and loads the bytecode file of the class from the network or a specific path;

[0066] Verification, preparation, and parsing phases, which are automatically completed by the virtual machine and are mainly responsible for verifying the correctness of the class, allocating memory for class variables and setting default values, and converting symbolic references to direct references. Custom class loaders have limited effects in these phases and usually do not change the execution order of the code;

[0067] Initialization phase: During the initialization phase, the virtual machine executes the initialization operations of the static code blocks and static variables of the class. The custom class loader indirectly affects the execution order of these operations by changing the bytecode of the class. The custom class loader modifies the initialization order of the static code blocks or static variables of the class when loading the class. These modifications will be reflected in the class initialization process.

[0068] Working principle, when using:

[0069] Custom class loader design, develop a custom class loader that can identify classes in a specific namespace and load these classes from a specified location. Custom class loader design is performed in Java. Custom class loader is implemented by inheriting ClassLoader class. This class loader overrides findClass method to load class bytecode from a specified path. You can choose to override loadClass method to control the class loading process. A mechanism for monitoring module file changes is added to the custom class loader. By regularly checking the timestamp of module files or file system listeners, Agent can dynamically modify Java bytecode, allowing developers to dynamically insert functions without modifying the target application source code. The functions include performance analysis, logging, code coverage testing and hot update. Through Agent, developers can monitor and analyze Java virtual machines and even intervene in the operation of virtual machines. Java's memory model allows custom class loaders to change the execution order of code during the upgrade process.

[0070] The Java class bytecode file detection includes the following: searching the device virtual machine process and selecting the specified process, then injecting the Agent into the specified virtual machine process to traverse the Class, finding the high-risk class and dumping the bytecode in the memory to the local. Finally, the YARA engine that creates malware families based on binary patterns is introduced to determine and summarize the bytecode matches stored locally. The modular design divides the judicial information system into multiple independent modules, each of which is responsible for a part of the business logic.

[0071] Java class bytecode file detection is completed by the Java process scanning module, Java process injection module, Agent extraction module, YARA rule loading module, rule matching module and report generation module. The Java process scanning module is used to scan the Java process running in the current system to obtain the PID and memory information of the Java process. The Java process injection module is used to inject the Agent into the specified Java. The Agent extraction module is used to perform Dupm of high-risk classes in the Class traversal stage. The YARA rule loading module is used to compile the rules in the rule file into useful rule objects while loading the YARA rule file.

[0072] The rule matching module is used to match the memory information with the UAR rules to determine whether the bytecode file of the Java class has been replaced or tampered with;

[0073] The report generation module is used to generate a detection report, which includes the detection results, the replaced or tampered information, and the malicious code

[0074] Version control, assigning version numbers to each module to facilitate management of module upgrades and rollbacks;

[0075] Hot update mechanism: when a new version of a module is deployed, the custom class loader detects the version change, unloads the old version of the class, and loads the new version of the class.

[0076] The above description is only a preferred specific implementation manner of the present invention, but the protection scope of the present invention is not limited thereto. Any technician familiar with the technical field can make equivalent replacements or changes according to the technical scheme and inventive concept of the present invention within the technical scope disclosed by the present invention, which should be covered by the protection scope of the present invention.

Claims

1. A modular hot loading method for judicial system based on Java custom class loader, characterized in that: include: Custom class loader design, develop a custom class loader that can identify classes within a specific namespace and load these classes from a specified location; Modular design divides the judicial information system into multiple independent modules, each of which is responsible for a part of the business logic; Version control, assigning version numbers to each module to facilitate management of module upgrades and rollbacks; Hot update mechanism: when a new version of a module is deployed, the custom class loader detects the version change, unloads the old version of the class, and loads the new version of the class.

2. According to claim 1, a modular hot loading method for a judicial system based on a Java custom class loader is characterized in that: The custom class loader is designed in Java and is implemented by inheriting the ClassLoader class. The class loader overrides the findClass method to load the bytecode of the class from the specified path. The loadClass method can be optionally overridden to control the class loading process.

3. According to claim 2, a modular hot loading method for a judicial system based on a Java custom class loader is characterized in that: A mechanism for monitoring module file changes is added to the custom class loader by periodically checking the timestamp of the module file or the file system listener.

4. According to claim 3, a modular hot loading method for a judicial system based on a Java custom class loader is characterized in that: The Agent can dynamically modify Java bytecode, allowing developers to dynamically insert functions without modifying the target application source code. The functions include performance analysis, logging, code coverage testing and hot update. Through the Agent, developers can monitor and analyze the Java virtual machine and even intervene in the operation of the virtual machine.

5. According to claim 4, a modular hot loading method for a judicial system based on a Java custom class loader is characterized in that: The Java class bytecode file detection includes the following contents: By searching the device virtual machine process and selecting the specified process; Then inject the Agent into the specified virtual machine process to traverse the Class, find the high-risk class and dump the bytecode in the memory to the local computer; Finally, the YARA engine, which creates malware families based on binary patterns, is introduced to determine and summarize the bytecode matches stored locally.

6. According to the method of modular hot loading of judicial system based on Java custom class loader in claim 5, it is characterized in that: The Java class bytecode file detection is completed by a Java process scanning module, a Java process injection module, an Agent extraction module, a YARA rule loading module, a rule matching module, and a report generation module; The Java process scanning module is used to scan the Java process running in the current system to obtain the PID and memory information of the Java process. The Java process injection module is used to inject the Agent into the specified Java. The Agent extraction module is used to perform Dupm of high-risk classes in the Class traversal stage.

7. According to claim 6, a modular hot loading method for a judicial system based on a Java custom class loader is characterized in that: The YARA rule loading module is used to compile the rules in the rule file into useful rule objects while loading the YARA rule file. The rule matching module is used to match the memory information with the UAR rules to determine whether the bytecode file of the Java class has been replaced or tampered with. The report generation module is used to generate a detection report, which includes the detection results, replacement or tampering information and malicious code.

8. According to claim 7, a modular hot loading method for a judicial system based on a Java custom class loader is characterized in that: The Java memory model allows a custom class loader to change the execution order of code during an upgrade. The Java memory model specifies how a Java virtual machine manages memory, including how to store and access object fields and methods and how to ensure data correctness and consistency in a multi-threaded environment. The Java memory model divides memory into several different areas, including a method area, a heap area, and a stack area. Each area has its specific purpose and management method.

9. A modular hot loading method for judicial system based on Java custom class loader according to claim 8, characterized in that: The Java class loading mechanism is an important manifestation of the dynamic nature of the Java language. The class loader is a component responsible for loading classes. It is used to load the bytecode file of the class into the memory and convert it into a class object recognized by the Java virtual machine. The Java class loading mechanism follows the parent delegation model. When a class loader needs to load a class, it will first try to delegate its parent class loader to load the class. Only when the parent class loader cannot load the class will it try to load it itself.

10. A modular hot loading method for judicial system based on Java custom class loader according to claim 9, characterized in that: The possibility of changing the order in which the code is executed; During the loading phase, the custom class loader changes the source of the class and loads the bytecode file of the class from the network or a specific path; Verification, preparation, and parsing phases, which are automatically completed by the virtual machine and are mainly responsible for verifying the correctness of the class, allocating memory for class variables and setting default values, and converting symbolic references to direct references. Custom class loaders have limited effects in these phases and usually do not change the execution order of the code; Initialization phase: During the initialization phase, the virtual machine executes the initialization operations of the static code blocks and static variables of the class. The custom class loader indirectly affects the execution order of these operations by changing the bytecode of the class. The custom class loader modifies the initialization order of the static code blocks or static variables of the class when loading the class. These modifications will be reflected in the class initialization process.

Images