A Java software version consistency detection method

Abstract

The application discloses a Java software version consistency detection method and relates to the version checking field.The application carries out hierarchical progressive checking, calculates the hash matching degree of new and old engineering files, analyzes the dependency configuration of the hash mismatched files to build a feature set, compares the dependency similarity, determines the version change at the architecture level when the dependency is changed, generates an AST after normalizing the source code, calculates the single-file consistency score based on the member semantic fingerprint, adds a cross-file identifier compensation check, finally builds an AST fingerprint set based on the single-file fingerprint, calculates the structural similarity, and sequentially forms four layers of judgment output results, namely, the file-level judgment of no version change, the architecture-level judgment of version change, the semantic-level judgment of no version change, and the semantic-level judgment of version change.The application combines file hash, engineering dependency and syntax tree semantics multidimensional checking, avoids single comparison misjudgment defects, improves the Java project version consistency detection precision, and is suitable for large batch automatic checking scenes.

Description

Technical Field

[0001] This invention relates to the field of software version verification technology, and in particular to a method for detecting Java software version consistency. Background Technology

[0002] As the pace of Java software development iterations accelerates, multiple versions of the same software can emerge. In scenarios such as project maintenance, version control, and vulnerability verification, frequent consistency comparisons between different software versions are necessary. Currently, the mainstream comparison methods in the industry have significant shortcomings, as follows: Simply relying on file hash comparison can only identify complete file changes, but cannot distinguish logical changes such as format adjustments, variable renaming, and code comment modifications. Comparing only the code text content is susceptible to errors due to formatting and naming conventions. Traditional syntax tree comparison only performs single-level node matching, does not distinguish between identifier name changes and business logic changes, and does not establish an identifier mapping compensation mechanism for cross-file dependency calls. When a method / field within a class is only renamed and the logic remains unchanged, the dependency file call verification will produce false judgments. The existing solution does not take into account the overall project dependencies, making it difficult to identify implicit changes at the engineering architecture level; For mainstream engineering development languages ​​like Java, projects contain a large number of dependency packages, configuration files, and source code files. Version changes are not only reflected in the code itself, but also include deep-level modifications such as adding or deleting dependency packages and upgrading versions. Existing single-dimensional comparison methods are either inefficient in detection or lack sufficient accuracy in judgment, failing to meet the dual requirements of rapid screening and accurate judgment, and are difficult to meet the use cases of large-scale automated software version verification. Summary of the Invention

[0003] To address the shortcomings of existing methods, this invention combines file hashing, project dependency list, and abstract syntax tree to construct a layered filtering mechanism, which gradually completes version verification from the surface to the depth.

[0004] The technical solution adopted in this invention is: a Java software version consistency detection method comprising the following steps: Step 1: Calculate the hash matching degree value of the project files in the new and old versions of the software respectively; use the hash matching degree value to determine the consistency between the two versions of the software; Furthermore, (1) in, Total number of project documents; , The old and new versions are respectively the first The hash value of each project file; It is the first version 'One project file;' For hash matching functions, These are the two input parameters of the hash matching function.

[0005] Step 2: For project files with hash mismatches, construct dependency feature sets for both versions using the dependency configuration files of the new and old software respectively, and calculate the dependency feature similarity value between the two versions. When the dependency feature similarity value is less than 1, perform syntax tree verification of the source code file; when the dependency feature similarity value is equal to 1, determine that the two software versions are consistent. Furthermore, the formula for relying on feature similarity values ​​is: (2) in, , These are the dependency feature sets for the old and new versions, respectively.

[0006] Step 3: Generate a standardized Java Abstract Syntax Tree (AST) from the source code files. Calculate the AST consistency score based on the semantic fingerprints of the AST members. Use the AST consistency score to perform version consistency judgment and cross-file compensation verification. Furthermore, step three specifically includes: Step 31: Perform normalization preprocessing on each source file in both the new and old versions; Step 32: Perform layered parsing of the preprocessed source code to generate a standardized Java Abstract Syntax Tree (AST); construct member semantic fingerprints using the core nodes of the AST. Step 33: Based on the semantic fingerprints of members in the old and new versions, calculate the AST consistency score of all source file pairs in both versions. ; Furthermore, in step 33, the AST consistency score... The assignment method is as follows: When the top-level node of the Java Abstract Syntax Tree (AST) and the member semantic fingerprints of the member nodes within a given source file pair in both the old and new versions completely match... ; When there are additions or deletions to the top-level node or class member node of a certain source file pair in the old and new versions, ; When the top-level node and class member nodes of a certain source file pair in the old and new versions have not been added or deleted, and the pseudo-substantial modification of the member logical characteristics is not performed, .

[0007] Step 34: During the process of comparing all old and new versions of source code files, once a discrepancy exists... If the value is -1, the process ends; otherwise, proceed to step 35. Step 35: Compare all old and new versions of the source code files, specifically... All old and new versions of the source code files in version 1 are used to build the global hash map. ;against All source files in the new version 0 undergo cross-file compensation verification. After the compensation verification is completed, a set of source files for the new version with compensation verification is obtained.

[0008] Furthermore, the source code file in step 31 undergoes preprocessing operations to remove spaces, newlines, redundant comments, and characters irrelevant to compilation.

[0009] Furthermore, cross-file compensation verification includes: Traversing the new version Extract the new version identifier of the call target from the method call nodes in the AST of all uncertain source files at that time. Query global hash map If a mapping relationship exists, the identifier of the new version member node will be replaced with the identifier of the old version member node.

[0010] Furthermore, member semantic fingerprints include: field fingerprints. Method fingerprint: .

[0011] Step 4: Construct fingerprint sets for the new and old versions after cross-file compensation verification; calculate the AST structure similarity value using the two fingerprint sets, and use the AST structure similarity value to determine version consistency. Steps one through four are used to generate four levels of judgment output results: file-level judgment of no version change, architecture-level judgment of version change, semantic-level judgment of no version change, and semantic-level judgment of version change.

[0012] Furthermore, the Java software version consistency detection system includes: a memory for storing instructions executable by a processor; and a processor for executing the instructions to implement the Java software version consistency detection method.

[0013] Furthermore, a computer-readable medium stores computer program code that implements a Java software version consistency detection method when executed by a processor.

[0014] The beneficial effects of this invention are: 1. Employs a three-tiered progressive filtering architecture based on hashing, dependency lists, and abstract syntax trees, combined with a consistency score for each source file. Dual quantization model of AST similarity; fingerprint set Based on a single source file The verification results are aggregated and generated, achieving a strong binding between global coarse-grained judgment and single-file fine-grained verification, balancing detection efficiency and judgment accuracy. It can quickly screen out versions without changes and is suitable for large-scale automated comparison of software versions. 2. Improve the accuracy of version change detection by determining whether a file has changed, whether the version has changed at the architecture level, and whether the version has changed at the semantic level. 3. By calculating the similarity of dependency features, it can accurately identify deep version changes in the project architecture and third-party dependencies, making up for the shortcomings of comparing a single source code file; 4. Add a source code normalization preprocessing step and innovatively design a member fingerprint generation mechanism based on modifiers, parameters, and implementations to completely isolate the interference of variable and method identifier renaming and achieve "only verify the logic, not the naming / format". 5. Added cross-file identifier mapping caching and call compensation verification mechanism to solve the problem of AST consistency misjudgment when only the class members are renamed but the logic remains unchanged in the case of multiple file dependencies, which greatly improves the verification accuracy of multi-module Java projects; 6. Redefine the set Constraining similarity calculation to a single source file The verification output addresses the shortcomings of traditional solutions, such as the disconnect between global and individual source file verification and poor judgment accuracy. 7. The entire process adopts standardized quantitative formulas and layered deterministic judgment logic, with clear rules, strong feasibility, and easy program development, automated deployment, and subsequent operation and maintenance. Attached Figure Description

[0015] Figure 1 This is a flowchart of the Java software version consistency detection method of the present invention, which includes three-level version determination branches: file level, architecture level, and semantic level. Detailed Implementation

[0016] The present invention will be further described below with reference to the accompanying drawings and embodiments. The drawings are simplified schematic diagrams, which only illustrate the basic structure of the present invention in a schematic manner, and therefore only show the components related to the present invention.

[0017] like Figure 1 As shown, a Java software version consistency detection method includes the following steps: Step 1: Calculate the hash matching degree value of the project files in the new and old versions of the software respectively; use the hash matching degree value to determine the consistency between the two versions of the software; The new version of the software is released after the old version; in this example, the new version of the software is B, and the old version of the software is A; the software development language is Java. Import two Java software version project files to be compared, batch calculate the hash values ​​of all project files, and use the hash matching degree value to perform file-level hash comparison to complete the file-level coarse screening; Project files include: Java project source code files and dependency configuration files, etc. The formula for hash matching degree is: (1) in, Total number of project documents; , The old and new versions are respectively the first The hash value of each project file; It is the first version 'One project file; hash matching function' Satisfy: When When the condition is met, the value is 1; otherwise, the value is 0. These are the two input parameters of the hash matching function; like If the software version is consistent, the file-level version is determined to be unchanged, and the process ends; if If so, proceed to step two of the verification process; Step one is used to perform a coarse screening to determine whether the file version has changed.

[0018] Step 2: For project files with hash mismatches, construct dependency feature sets for both versions using the dependency configuration files of the new and old software respectively, and calculate the dependency feature similarity value between the two versions. When the dependency feature similarity value is less than 1, perform syntax tree verification of the source code file; when the dependency feature similarity value is equal to 1, determine that the two software versions are consistent. The dependency configuration files for both the old and new versions of the Java project are parsed to extract all dependencies, version information, and topology relationships. The group ID, module name, and version number are concatenated to obtain the dependency feature set. , ; Java project dependency configuration files: groupId is the group ID, artifactId is the module name, and version is the version number. <dependencies> <dependency> <groupid> org.apache.aaa< / groupid> <artifactid> bbb< / artifactid> <version> 1.0< / version> < / dependency> < / dependencies> Parsing the dependency feature set: {dependency: org.apache.aaa.bbb: 1.0 [complie],..}

[0019] The formula for feature similarity is: (2) in, , These are the dependency feature sets for the old and new versions, respectively.

[0020] use Determine if there are any dependency changes, including version updates and dependency adjustments. when If the time indicates that the dependency has not changed, that is, the architecture-level determination of the version has not changed, then continue to the syntax tree verification step of the source code file in step three; when If the software version is inconsistent, the architecture-level determination of the version change will be made, and the process will end. Step two completes the architecture-level determination of version changes.

[0021] Step 3: Generate a standardized Java Abstract Syntax Tree (AST) from the source code files. Calculate the AST consistency score based on the semantic fingerprints of the AST members. Use the AST consistency score to perform version consistency judgment and cross-file compensation verification. Step 31: Perform normalization preprocessing on each source file in both the new and old versions; Preprocessing includes: removing spaces, newlines, redundant comments, and removing characters irrelevant to compilation.

[0022] Step 32: Parse the two versions of preprocessed source code respectively, analyze the AST node structure layer by layer, and generate a standardized Java Abstract Syntax Tree (AST); construct member semantic fingerprints using the core nodes of the Java Abstract Syntax Tree (AST); The Java Abstract Syntax Tree (AST) contains three core nodes. The first layer is the top-level node, which includes: the package node and the imports collection node; The second layer is the type root node types, which includes: the qualified name identifier of the node storage class and the body member of the child node carrying class; The third layer consists of class member nodes, including: member variables (field) and member methods (method); member variables include: variable name, modifier, variable type, and initialization assignment; member methods include: method name, modifier, parameter list, return type, and method implementation body; the method implementation body includes: local variables and method call; method call includes: direct call to expression.identify and chained call to expression.name.

[0023] Member semantic fingerprints include: field fingerprints and method fingerprints; Field fingerprint: ; Method fingerprint: ; private List f1;

[0024] The fingerprint field example above; variable name = f1, modifier = private, variable type = List, initialized to null; public BigDecimal multi(BigDecimal d1,BigDecimal d2) { return d1.multiply(d2); }

[0025] The above is an example of a fingerprint method; modifier = public; input parameter list = BigDecimal, d1; BigDecimal, d2; return type = BigDecimal; method implementation body = {return d1.multiply(d2)}; Step 33: Based on the semantic fingerprints of members in the old and new versions, calculate the AST consistency score of all source file pairs in both versions. ; in, i Indicates the first i One source code file; Calculating all source code file pairs in two versions can be done sequentially or randomly; for example, if A and B contain 10 source code files, A1B1 to A... can be calculated sequentially. 10 B 10 Alternatively, you can randomly execute A2B2, A1B1, A9B9, ..., A4B4, and iterate through them all. AST consistency score in step 33 The assignment method is as follows: When the top-level node of the Java Abstract Syntax Tree (AST) and the member semantic fingerprints of the member nodes within a given source file pair in both the old and new versions completely match... ; When the semantic fingerprints of the members match perfectly, there is no need to consider whether there is identifier renaming. When there are additions or deletions to the top-level node or class member node of a certain source file pair in the old and new versions, ; When the top-level node and class member nodes of a certain source file pair in the old and new versions have not been added or deleted, and the member logical characteristics have been pseudo-substantively modified (substantial modification may have occurred), ; Member semantic fingerprints are used to determine whether or potentially to modify the logical characteristics of a member. Member semantic fingerprints are used to remove identifier interference and only represent the member's business logic. The same member semantic fingerprint means that the member's logic has not changed.

[0026] Step 34: During the process of comparing all old and new versions of source code files, once a discrepancy exists... If the value is -1, the process ends and a semantic-level change is determined; otherwise, step 35 is executed. Step 35: Compare all old and new versions of the source code files, specifically... All old and new versions of source code files in version 1 are used to build a hash cache mapping new and old identifiers; targeting All source files in the new version 0 undergo cross-file compensation verification. After the compensation verification is completed, the set of source files for the new version is obtained; the set of source files for the new version is the new... The new version; Furthermore, a hash cache mapping between new and old identifiers is established: a global hash map is created. The key is the identifier of the new version member method, and the value is the identifier of the old version member method corresponding to the semantic fingerprint of the same member in the new version. This is used for cross-file compensation verification.

[0027] Furthermore, cross-file compensation verification includes: Traversing the new version Extract the new version identifier of the call target from the method call nodes in the AST of all uncertain source files at that time. Query global hash map If a mapping relationship exists, the identifier of the new version member node will be replaced with the identifier of the old version member node.

[0028] By effectively isolating the interference of member method identifier renaming, consistency verification can be achieved by "verifying only the logic and not the naming / format", thereby improving the verification accuracy.

[0029] For example: Version A contains source code files A1, A2, and A3; Version B contains source code files B1, B2, and B3; A1 and B1 are a pair of source code files. First, compare A1 and B1. If C1 calculated by A1 and B1 is -1, then there is no need to calculate C2 and C3, and the process ends. If C1 calculated by A1 and B1 is 1, then a global hash map of A1B1 is established. Next, calculate C2; ​​if C2 = -1, then there is no need to calculate C3, and the process ends; if C2 = 0, then calculate C3. If C3 = -1, the process ends; If C3=1, then establish the global hash mapping A3B3. Then utilize the global hash mapping of A1B1 and A3B3 Perform cross-file compensation verification on B2; If C3=0, then use the global hash mapping of A1B1. Perform cross-file compensation verification on B2 and B3; A1: Example of a Java source code file: package org.example.msgbotdemo; import java.math.BigDecimal; import java.util.List; public class Class1 { private List f1; public BigDecimal multi(BigDecimal d1,BigDecimal d2) { return d1.multiply(d2); } } B1: Example of a Java source code file that has not undergone substantial modification: package org.example.msgbotdemo; import java.math.BigDecimal; import java.util.List; public class Class1 { private List f1; public BigDecimal multiRename(BigDecimal d1,BigDecimal d2) { return d1.multiply(d2); }

[0030] If the identifier "multi" in source file A1 of version A is renamed to "multiRename" in source file B1 of version B, it means that no substantial modification has occurred. ; (multiRename, multi); A1: Example of a Java source code file: package org.example.msgbotdemo; import java.math.BigDecimal; import java.util.Map; public class Class1 { private Map f1; public BigDecimal multi(BigDecimal d1,BigDecimal d2) { return d1.multiply(d2); } } B1: Example of a Java source code file that has undergone substantial modifications: package org.example.msgbotdemo; import java.math.BigDecimal; import java.util.Map; import java.util.List; public class Class1 { private Map f1; private List f2; public BigDecimal multi(BigDecimal d1,BigDecimal d2) { return d1.add(d2); } }

[0031] As shown above, B1 adds a top-level node `import java.util.List` compared to A1, and also adds a class member node `private List f2`, indicating that a substantial modification has occurred. ; A1: Example of a Java source code file: package org.example.msgbotdemo; import java.math.BigDecimal; import java.util.Map; import java.util.List; public class Class1 { private Map f1; private List f2; public BigDecimal multi(BigDecimal d1,BigDecimal d2) { return d1.add(d2); } } B1: Example of a Java source code file that has undergone substantial modifications: package org.example.msgbotdemo; import java.math.BigDecimal; import java.util.Map; public class Class1 { private Map f1; public BigDecimal multi(BigDecimal d1,BigDecimal d2) { return d1.multiply(d2); } }

[0032] As shown in the example above, B1 removes the top-level node `import java.util.List` and the class member node `private List f2` compared to A1, indicating a substantial modification. ; A1: Example of a Java source code file: package org.example.msgbotdemo; import java.math.BigDecimal; import java.util.Map; public class Class1 { private Map f1; public BigDecimal multi(BigDecimal d1,BigDecimal d2) { return d1.multiply(d2); } } B1: Example of a Java source code file that has undergone substantial modifications: package org.example.msgbotdemo; import java.math.BigDecimal; import java.util.Map; public class Class1 { private Map f1; private Map f2; public BigDecimal multi(BigDecimal d1,BigDecimal d2) { return d1.add(d2); } }

[0033] If, compared to A1, B1 adds a new private map f2, a member node within the class, then a substantial modification has occurred. ; A1: Example of a Java source code file: package org.example.msgbotdemo; import java.math.BigDecimal; import java.util.Map; public class Class1 { private Map f1; private Map f2; public BigDecimal multi(BigDecimal d1,BigDecimal d2) { return d1.multiply(d2); } } B1: Example of a Java source code file that has undergone substantial modifications: package org.example.msgbotdemo; import java.math.BigDecimal; import java.util.Map; public class Class1 { private Map f1; public BigDecimal multi(BigDecimal d1,BigDecimal d2) { return d1.add(d2); } }

[0034] As shown above, B1 deletes the private Map f2, a member node within the class, compared to A1, indicating a substantial modification. ; A2: Example of the caller's Java source code file: public class Class2 { private Class1 class1; public BigDecimal call(BigDecimal d1,BigDecimal d2) { return class1.multi(d1, d2); } } B2: Example of Java source code file with pseudo-substance modification of member logic characteristics: public class Class2 { private Class1 class1; public BigDecimal call(BigDecimal d1,BigDecimal d2) { d1=d2; return class1.multiRename (d1,d2); } }

[0035] When C2=0, there are no additions or deletions to the top-level nodes and class member nodes in versions B2 and A2. Furthermore, the identifier for the Class2 calling node in version A2 is "multi," and the identifier for the Class2 calling node in version B2 is "multiRename" (pseudo-substantial modification of member logical characteristics). Therefore, the global hash mapping formed between A1 and B1... If a mapping of multi to multiRename is found in B2, then the node identifier that calls B1 will be replaced with multi in B2 by multiRename. It can be seen that although B2 has completed the cross-file compensation verification, further comparison is still needed in step four because of the modification d1=d2 in B2.

[0036] Step 4: Construct fingerprint sets for the new and old versions after cross-file compensation verification; calculate the AST structure similarity value using the two fingerprint sets, and use the AST structure similarity value to determine version consistency. use The new version of the fingerprint set is constructed from a single set of source files. ;use The collection of source code files from older versions, build version A fingerprint collection ;use and Calculate AST structural similarity Output the final consistency determination result; The fingerprint of a single source file in the fingerprint set consists of node tree serialization, top-level node, and field fingerprints. Method fingerprint Concatenate and calculate the hash string; as shown below; Top-level node merging: package:org.example.msgbotdemo§import:java.math.BigDecimal,java.util.List§public#Class1 String characteristics of member variable nodes: f1#private#List#NULL String characteristics of member method nodes: public#BigDecimal#BigDecimal,d1;BigDecimal,d2#{returnd1.multiply(d2);}; Fingerprint of a source file: Hash(package:org.example.msgbotdemo§import:java.math.BigDecimal,java.util.List§public#Class1§[hash(f1#private#List#NULL )]§[hash(public#BigDecimal#BigDecimal,d1;BigDecimal,d2#{returnd1.multiply(d2);})])

[0037] AST similarity The formula is: (3) like This means that the number of fingerprints and the implementation logic of all Java files in the project are completely consistent, with only changes in code format and member identifier renaming, and no changes to business logic; the software version is also consistent, and the semantic-level determination shows no version change, and the process ends. like This indicates that at least one file's code business logic has undergone substantial changes, indicating a software version inconsistency. A version change is determined semantically, and the process ends.

[0038] Steps three and four are used to determine whether the version has changed at the semantic level.

[0039] Based on the above-described preferred embodiments of the present invention, and through the foregoing description, those skilled in the art can make various changes and modifications without departing from the inventive concept. The technical scope of this invention is not limited to the contents of the specification, but must be determined according to the scope of the claims.

Claims

1. A method for detecting Java software version consistency, characterized in that, Includes the following steps: Step 1: Calculate the hash matching degree value of the project files in the new and old versions of the software respectively; use the hash matching degree value to determine the consistency between the two versions of the software; Step 2: For project files with hash mismatches, construct dependency feature sets for both versions using the dependency configuration files of the new and old software respectively, and calculate the dependency feature similarity value between the two versions. When the dependency feature similarity value is less than 1, perform syntax tree verification of the source code file; when the dependency feature similarity value is equal to 1, determine that the two software versions are consistent. Step 3: Generate a standardized Java Abstract Syntax Tree (AST) from the source code files. Calculate the AST consistency score based on the semantic fingerprints of the AST members. Use the AST consistency score to perform version consistency judgment and cross-file compensation verification. Step 4: Construct fingerprint sets for the new and old versions after cross-file compensation verification; calculate the AST structure similarity value using the two fingerprint sets, and use the AST structure similarity value to determine version consistency.

2. The Java software version consistency detection method according to claim 1, characterized in that, Step three specifically includes: Step 31: Perform normalization preprocessing on each source file in both the new and old versions; Step 32: Perform layered parsing of the preprocessed source code to generate a standardized Java Abstract Syntax Tree (AST); construct member semantic fingerprints using the core nodes of the AST. Step 33: Based on the semantic fingerprints of members in the old and new versions, calculate the AST consistency score of all source file pairs in both versions. ; Step 34: During the process of comparing all old and new versions of source code files, once a discrepancy exists... If the value is -1, the process ends; otherwise, proceed to step 35. Step 35: Compare all old and new versions of the source code files, specifically... All old and new versions of the source code files in version 1 are used to build the global hash map. ;against All source files in the new version 0 undergo cross-file compensation verification. After the compensation verification is completed, a set of source files for the new version with compensation verification is obtained.

3. The Java software version consistency detection method according to claim 2, characterized in that, AST consistency score in step 33 The assignment method is as follows: When the top-level node of the Java Abstract Syntax Tree (AST) and the member semantic fingerprints of the member nodes within a given source file pair in both the old and new versions completely match... ; When there are additions or deletions to the top-level node or class member node of a certain source file pair in the old and new versions, ; When the top-level node and class member nodes of a certain source file pair in the old and new versions have not been added or deleted, and the pseudo-substantial modification of the member logical characteristics is not performed, .

4. The Java software version consistency detection method according to claim 2, characterized in that, Cross-file compensation verification includes: Traversing the new version Extract the new version identifier of the call target from the method call nodes in the AST of all uncertain source files at that time. Query global hash map If a mapping relationship exists, the identifier of the new version member node will be replaced with the identifier of the old version member node.

5. The Java software version consistency detection method according to claim 2, characterized in that, Member semantic fingerprints include: field fingerprints Method fingerprint .

6. The Java software version consistency detection method according to claim 1, characterized in that, The formula for hash matching degree is: (1) in, Total number of project documents; , The old and new versions are respectively the first The hash value of each project file; It is the first version 'One project file;' For hash matching functions, These are the two input parameters of the hash matching function.

7. The Java software version consistency detection method according to claim 1, characterized in that, The formula for feature similarity is: (2) in, , These are the dependency feature sets for the old and new versions, respectively.

8. The Java software version consistency detection method according to claim 2, characterized in that, The normalization preprocessing in step 31 includes: removing spaces, newlines, and redundant comments from the source code file, and removing characters irrelevant to compilation.

9. A Java software version consistency detection system, characterized in that, include: Memory is used to store instructions that can be executed by the processor; A processor for executing instructions to implement the Java software version consistency detection method as described in any one of claims 1-8.

10. A computer-readable medium storing computer program code, characterized in that, The computer program code implements the Java software version consistency detection method as described in any one of claims 1-8 when executed by a processor.

Images