CN112965913B - Java software dependency conflict problem automatic repairing method - Google Patents

Abstract

The application discloses a method for automatically repairing Java software dependency conflict problems, which finds out the dependency conflict problems by analyzing the dependency relationship of Java software items, and obtains classes and methods realized by a program and possible call paths between the classes and the methods by static analysis. According to the application, 4 repair strategies are set, different strategies are selected according to the risk types, the risk-free version is loaded into the current project, and an appropriate dependent version is selected according to the calling path relation of the project to perform automatic version replacement, so that a developer is helped to effectively avoid the problem of dependence conflict. And the method can evaluate whether more dependence conflicts which can cause errors in running can be brought to the project while repairing, and finally, repairing patches and repairing reports can be automatically formed to developers. The probability of running errors encountered by a developer in the development process is reduced, the time for solving the running errors is shortened, and the development cost is saved.

Description

A method for automatically repairing Java software dependency conflict problems

Technical field

The invention relates to the technical field of software reliability, and in particular to a method for automatically repairing Java software dependency conflict problems.

Background technique

With the efforts of many developers, Java software has formed a huge third-party open source dependency library. Although third-party open source dependency libraries have brought great convenience to developers in developing Java software projects, they have also brought trouble to developers, that is, how to manage many third-party dependency packages introduced in Java software projects. When a Java software project introduces a third-party dependency package, and the development of the third-party dependency package introduces other third-party dependency packages, a transfer situation is formed. This situation prevents the Java software project from supporting the third-party dependency package. management. Therefore, the emergence of Maven brings a good build management solution to Java software projects. Maven is the main construction tool for Java projects and the main management tool for third-party open source projects introduced by Java projects. By injecting the required third-party dependencies through the configuration file, Maven can automatically obtain all the dependency packages required by the project. This not only solves the management problem of third-party dependent packages in Java software projects, but also provides great convenience for the development of Java software projects.

As a good solution for Java build management, Maven can effectively manage third-party dependency packages, but it can also cause problems. A third-party dependency package often undergoes function updates, problem fixes, etc. After multiple update iterations, multiple versions will be produced. Since the dependency packages required for the dependency are transitively introduced when the dependency package is introduced, a Java software project often has multiple versions of the same dependency package. According to Maven's dependency management mechanism, only one version will be loaded into the project, while other versions will be blocked, resulting in dependency conflicts. After a third-party dependency package is iteratively updated, it may happen that a certain class or method exists in one version but not in another version. When the project uses this method but actually loads a dependency version that does not contain this method. , an error will occur at runtime. When a Java software project has dependency conflicts and insufficient integration testing, the dependency conflicts may produce unexpected runtime errors when the project is running, such as java.lang.NoClassDefFoundError and java.lang.NoSuchMethodError. . Although Maven itself can identify dependency conflicts, it lacks an effective mechanism to help developers fix dependency conflicts.

The Maven build tool does not provide an effective solution to the problem of runtime errors caused by dependency conflicts in the Maven environment. Once you encounter a runtime error, you need to spend a lot of time looking for the class and method that triggered the error, and then looking for ways to fix the error. Repairing dependency conflicts by analyzing the relationship between classes and methods within the program can further help software developers avoid program runtime crashes.

Contents of the invention

The technical problem to be solved by the present invention is to provide a method for automatically repairing Java software dependency conflict problems in view of the shortcomings of the above-mentioned existing technologies.

In order to solve the above technical problems, the technical solution adopted by the present invention is: a method for automatically repairing Java software dependency conflict problems, including the following steps:

Step 1: Get the project code and dependencies of the current project;

Step 2: Analyze the dependencies of the current project, obtain the risk dependency conflicts and the risk methods called, and divide the risk dependency conflicts into conflicts with direct dependencies and conflicts without direct dependencies. The process is as follows:

Step 2.1: Traverse the complete dependency tree of the current project, and analyze the dependencies that exist in multiple versions in the complete dependency tree, which are defined as dependency conflicts;

Step 2.2: For the analyzed dependency conflicts, compare and analyze the classes and methods in the loaded version and the unloaded version jar package. If a method in the unloaded version jar package does not have a corresponding method with the same qualified name in the loaded version jar package , then it is a risk method. Obtain such a method collection and determine whether the method in the collection is called in the current project. If there is a call, it is a risk dependency conflict. Obtain the called risk method;

Step 2.3: For risky dependency conflicts, check whether the conflicting loaded version is a directly declared dependency of the current project through the dependency diagram. If it is a directly declared dependency of the current project, it is a conflict with direct dependency; otherwise, it is a conflict with no direct dependency. .

Step 3: Analyze risky dependency conflicts and find risk-free dependency versions by judging whether the methods in the loaded dependency versions satisfy all calls in the current project. The process is as follows:

Step 3.1: For risk dependency conflicts, analyze whether the method of the unloaded dependency version satisfies all calls of the method of the loaded dependency version in the project. If it is satisfied, the unloaded version is a risk-free version and enter step 3.5; if not , go to the next step;

Step 3.2: Obtain all releases that the risk depends on, delete the versions that exist in the risk conflict, filter versions with lower version numbers than those in the risk conflict, and remove the test version from the filtered version set in turn;

Step 3.3: Obtain the jar package of the test version, and analyze whether the methods in the test version satisfy all calls of the methods in the loaded dependent version in the project. If so, go to the next step; if not, test the next version;

Step 3.4: Analyze whether the method in the test version contains the risk method called in the unloaded dependency version. If so, it is a risk-free version;

Step 3.5: The obtained unloaded version or test version is a risk-free version.

Step 4: Set the repair strategy, select different strategies according to the risk type, and load the risk-free version into the current project;

The repair strategies include the following four types:

1: Replace the direct dependencies of the current project: Read the dependency configuration file of the current project, locate the declaration location of the target's direct dependencies, and perform version replacement;

2: Use the <dependencyManagement> tag to unify to a risk-free version;

3: Use the <exclude> tag to delete the currently used version;

4: Directly declare the risk-free version: Read the dependency configuration file of the current project and directly add a declaration of dependence on the risk-free version.

The process of selecting different strategies according to the risk type to load the risk-free version into the current project is as follows:

Step 4.1: After obtaining the risk-free version, determine the type of risk dependency conflict. If it is a conflict with direct dependencies, use strategies 1 and 2 in the repair strategy to replace the version and generate a temporary repair patch; if it is a conflict with no direct dependencies, If there is a conflict, use strategies 2, 3, and 4 to perform version replacement and generate a temporary repair patch;

Step 4.2: For repair patches corresponding to different replacement strategies, analyze the dependencies after replacement and obtain the loaded version after current conflict replacement. If the risk-free version is loaded correctly, the replacement is successful; if the risk-free version is not loaded correctly, the replacement fails. , delete the temporary repair patch corresponding to the failed replacement strategy.

Step 5: Evaluate whether the project using the repair strategy generates new dependency conflicts. The process is as follows:

Step 5.1: Traverse all temporary repair patches in sequence and obtain the dependencies generated by the temporary repair patches;

Step 5.2: Compare the new dependencies generated by the patch with the original dependencies of the project to see if there is a dependency conflict that is different from the original project. If so, go to the next step; if not, go to step 5.4;

Step 5.3: Comparatively analyze the classes and methods in the loaded version and the unloaded version jar package. If a method in the unloaded version jar package does not have a corresponding method with the same qualified name in the loaded version jar package, it is a risky method. Obtain such a method collection and determine whether the methods in the collection are called in the current project. If there are calls, the repair patch will be invalid; if there are no calls, go to the next step;

Step 5.4: Back up the successfully evaluated temporary repair patch to the user-specified folder.

Step 6: Push fix suggestions and fix patches to developers.

The beneficial effect of adopting the above technical solution is that the method provided by the present invention can not only identify dependency conflicts that may produce runtime errors, but also provide reasonable repair solutions for these dependency conflicts that may produce runtime errors. Only by using the method of the present invention in the target Java project, corresponding repair suggestions and repair patches can be obtained, which reduces the probability of developers encountering runtime errors and the time to solve runtime errors during the development process, and saves development time cost.

Description of the drawings

Figure 1 is a flow chart of a method for automatically repairing Java software dependency conflict problems in an embodiment of the present invention;

Figure 2 is a flow chart for obtaining a risk-free dependency version in an embodiment of the present invention;

Figure 3 is a flow chart of using a repair strategy to replace a risk-free version in an embodiment of the present invention;

Figure 4 is a flow chart for evaluating whether the repair strategy is effective in an embodiment of the present invention.

Detailed ways

Specific implementations of the present invention will be described in further detail below with reference to the accompanying drawings and examples. The following examples are used to illustrate the invention but are not intended to limit the scope of the invention.

As shown in Figure 1, the method for automatically repairing Java software dependency conflict problems in this embodiment is as follows:

Step 1: Get the project code and dependencies of the current project;

In this embodiment, the project pom file is parsed through Maven to obtain the project's complete dependency tree. Because the Maven loading mechanism ensures that only one version of each dependency is loaded and used, a complete dependency tree includes the project's loaded dependencies and unused dependencies. The loaded dependency traverses the complete dependency tree, and each dependency on the dependency tree is regarded as a node and stored in the container of the program. Each node stores information including groupId, artifactavtId, version, isUsed, manage, parent, etc. .

Step 2: Analyze the dependencies of the current project, obtain the risk dependency conflicts and the risk methods called, and divide the risk dependency conflicts into conflicts with direct dependencies and conflicts without direct dependencies. The process is as follows:

Step 2.1: Traverse the complete dependency tree of the current project, and analyze the dependencies that exist in multiple versions in the complete dependency tree, which are defined as dependency conflicts;

In this embodiment, because each dependency has a unique groupId and ArtifactId, if a dependency with the same groupId and the same artifactId appears in the complete dependency tree, but the versions of the dependencies are different, a dependency conflict will occur. Because the project will only use one of the versions, check the isUsed value of the dependency. If it is true, it is defined as the loaded version depends on usedDepJar; if it is false, the unloaded version depends on unusedDepJar. Place all dependency conflicts identified into a dependency conflict container.

Step 2.2: For the analyzed dependency conflicts, compare and analyze the classes and methods in the loaded version and the unloaded version jar package. If a method in the unloaded version jar package does not have a corresponding method with the same qualified name in the loaded version jar package , then it is a risk method. Obtain such a method collection and determine whether the method in the collection is called in the current project. If there is a call, it is a risk dependency conflict. Obtain the called risk method;

In this embodiment, the dependency conflict container is traversed, and for each dependency conflict, the classes and methods in the jar package of the loaded version and the unloaded version are parsed. For the parsed method, if the method is not implemented in the loaded version and is not implemented in the unloaded version, If there is an implementation in the loaded version, it will be stored in the testMethods set. Use soot to generate the call graph of the project, using the methods in the project as the starting point. If you can address the methods in the testMethods set, it is a risky dependency conflict. Add this method to the riskMethods set.

Step 2.3: For risky dependency conflicts, check whether the conflicting loaded version is a directly declared dependency of the current project through the dependency diagram. If it is a directly declared dependency of the current project, it is a conflict with direct dependency; otherwise, it is a conflict with no direct dependency. .

In this embodiment, for each risk dependency conflict, the parent value of the loaded version usedDepJar is obtained. If the parent value of the node is not empty, it is a conflict Type A with no direct dependency; otherwise, it is a conflict Type A with direct dependencies. B.

Step 3: Analyze risky dependency conflicts and find risk-free dependency versions by judging whether the methods in the loaded dependency versions satisfy all calls in the current project. The process is shown in Figure 2. The process is as follows:

Step 3.1: For risk dependency conflicts, analyze whether the method of the unloaded dependency version satisfies all calls of the method of the loaded dependency version in the project. If it is satisfied, the unloaded version is a risk-free version and enter step 3.5; if not , go to the next step;

In this embodiment, for each risky dependency conflict, all methods in the loaded version jar package are parsed, and the call graph of the project is generated through soot. Taking the method in the project as a starting point, if the method in the loaded version can be addressed, the method is added to the usedMethods set. Analyze whether the method of the unloaded version contains all methods in the usedMethods set. If it does, the unloaded version is a risk-free and safe version. Go to step 3.5. Otherwise, go to the next step.

Step 3.2: Obtain all releases that the risk depends on, delete the versions that exist in the risk conflict, filter versions with lower version numbers than those in the risk conflict, and remove the test version from the filtered version set in turn;

In this embodiment, all released versions of conflicting dependencies are obtained from the Maven warehouse, these versions are traversed, the loaded and unloaded versions of conflicting dependencies are deleted, and the remaining versions are sorted from high to low and stored in the version set versions. Take out the versions from versions in sequence and obtain the dependent jar package of this version.

Step 3.3: Obtain the jar package of the test version, and analyze whether the methods in the test version satisfy all calls of the methods in the loaded dependent version in the project. If so, go to the next step; if not, test the next version;

In this embodiment, the methods in the test version jar package are parsed to obtain the usedMethods set in step 3.1. If the methods in the test version jar package can include all methods in the usedMethods set, go to the next step; otherwise, try other versions.

Step 3.4: Analyze whether the method in the test version contains the risk method called in the unloaded dependency version. If so, it is a risk-free version;

In this embodiment, the riskMethods collection in step 2.2 is obtained. If the methods in the test version jar package include all methods in the riskMethods collection, the test version is a risk-free safe version; otherwise, try the next version.

Step 3.5: The obtained unloaded version or test version is a risk-free version.

Step 4: Set the repair strategy, select different strategies according to the risk type, and load the risk-free version into the current project;

The repair strategies include the following four types:

1: Replace the direct dependencies of the current project: Read the dependency configuration file of the current project, locate the declaration location of the target's direct dependencies, and perform version replacement;

2: Use the <dependencyManagement> tag to unify to a risk-free version;

3: Use the <exclude> tag to delete the currently used version;

4: Directly declare the risk-free version: Read the dependency configuration file of the current project and directly add a declaration of dependence on the risk-free version.

The process of selecting different strategies according to the risk type to load the risk-free version into the current project is shown in Figure 3, including the following process:

Step 4.1: After obtaining the risk-free version, determine the type of risk dependency conflict. If it is a conflict with direct dependencies, use strategies 1 and 2 in the repair strategy to replace the version and generate a temporary repair patch; if it is a conflict with no direct dependencies, If there is a conflict, use strategies 2, 3, and 4 to perform version replacement and generate a temporary repair patch;

In this embodiment, the project pom.xml file is read, the code segment with risk conflict is located, and the code segment of the repair strategy is used for replacement. The replaced file is named pom-repair*.xml in combination with the repair strategy serial number used. .

Step 4.2: For repair patches corresponding to different replacement strategies, analyze the dependencies after replacement and obtain the loaded version after current conflict replacement. If the risk-free version is loaded correctly, the replacement is successful; if the risk-free version is not loaded correctly, the replacement fails. , delete the temporary repair patch corresponding to the failed replacement strategy.

In this embodiment,: obtain the dependency relationship of each pom-repair*.xml, check whether the loaded version with risk dependency conflict is a replaced version, if the replaced version is loaded correctly, copy the pom-copy.xml file to a temporary The repair patch is in the temp folder; if the risk-free version is not loaded correctly, the replacement will fail.

Step 5: Evaluate whether the project using the repair strategy generates new dependency conflicts. The process is shown in Figure 4. The process is as follows:

Step 5.1: Traverse all temporary repair patch pom-copy.xml in sequence to obtain the dependencies generated by the temporary repair patch;

Step 5.2: Compare the new dependencies generated by the patch with the original dependencies of the project to see if there is a dependency conflict that is different from the original project. If so, go to the next step; if not, go to step 5.4;

In this embodiment, the dependency relationship of the temporary repair patch is analyzed to obtain a new dependency conflict set newConflicts. By limiting the groupId and artifactId values, it is checked whether a dependency conflict that does not exist in the original dependency conflict set appears in the newConflicts set. If it occurs, it is defined as a new one. If there is a dependency conflict, go to the next step; if it does not occur, go to step 5.4.

Step 5.3: Comparatively analyze the classes and methods in the loaded version and the unloaded version jar package. If a method in the unloaded version jar package does not have a corresponding method with the same qualified name in the loaded version jar package, it is a risky method. Obtain such a method collection and determine whether the methods in the collection are called in the current project. If there are calls, the repair patch will be invalid; if there are no calls, go to the next step;

In this embodiment, for new dependency conflicts, the classes and methods in the jar packages of the loaded version and the unloaded version are parsed. For the parsed method, if the method is not implemented in the loaded version but is implemented in the unloaded version , then it is stored in the testMethod set. Use soot to generate the call graph of the project, using the methods in the project as the starting point. If the method in the testMethod set can be addressed, the repair patch will be invalid.

Step 5.4: Back up the successfully evaluated temporary repair patch to the user-specified folder.

Step 6: Push fix suggestions and fix patches to developers.

In this embodiment, a repair suggestion report is generated in the form of a text file, and the report includes detailed information of risky dependency conflicts (loaded version number and unloaded version number, dependency structure in the dependency tree, calling path of risky methods, etc.), Available remediation strategies proposed for risky dependency conflicts and file paths to remediation patches.

Claims (5)

1. A method for automatically repairing Java software dependency conflict problems, which is characterized by including the following steps: Step 1: Get the project code and dependencies of the current project; Step 2: Analyze the dependencies of the current project, obtain the risk dependency conflicts and the risk methods called, and divide the risk dependency conflicts into conflicts with direct dependencies and conflicts without direct dependencies; Step 3: Analyze risky dependency conflicts and find risk-free dependency versions by judging whether the methods in the loaded dependency versions satisfy all calls in the current project; Step 3.1: For risk dependency conflicts, analyze whether the method of the unloaded dependency version satisfies all calls of the method of the loaded dependency version in the project. If it is satisfied, the unloaded version is a risk-free version and enter step 3.5; if not , go to the next step; Step 3.2: Obtain all releases that the risk depends on, delete the versions that exist in the risk conflict, filter versions with lower version numbers than those in the risk conflict, and remove the test version from the filtered version set in turn; Step 3.3: Obtain the jar package of the test version, and analyze whether the methods in the test version satisfy all calls of the methods in the loaded dependent version in the project. If so, go to the next step; if not, test the next version; Step 3.4: Analyze whether the method in the test version contains the risk method called in the unloaded dependency version. If so, it is a risk-free version; Step 3.5: The obtained unloaded version or test version is a risk-free version; Step 4: Set the repair strategy, select different strategies according to the risk type, and load the risk-free version into the current project; Step 5: Evaluate whether the project using the repair strategy generates new dependency conflicts; Step 6: Push fix suggestions and fix patches to developers. 2. The method for automatically repairing Java software dependency conflict problems according to claim 1, characterized in that the process of step 2 is as follows: Step 2.1: Traverse the complete dependency tree of the current project, and analyze the dependencies that exist in multiple versions in the complete dependency tree, which are defined as dependency conflicts; Step 2.2: For the analyzed dependency conflicts, compare and analyze the classes and methods in the loaded version and the unloaded version jar package. If a method in the unloaded version jar package does not have a corresponding method with the same qualified name in the loaded version jar package , then it is a risk method. Obtain such a method collection and determine whether the method in the collection is called in the current project. If there is a call, it is a risk dependency conflict. Obtain the called risk method; Step 2.3: For risky dependency conflicts, check whether the conflicting loaded version is a directly declared dependency of the current project through the dependency diagram. If it is a directly declared dependency of the current project, it is a conflict with direct dependency; otherwise, it is a conflict with no direct dependency. . 3. The method for automatically repairing Java software dependency conflict problems according to claim 1, characterized in that the repair strategy includes the following four types: 1: Replace the direct dependencies of the current project; 2: Use the <dependencyManagement> tag to unify to a risk-free version; 3: Use the <exclude> tag to delete the currently used version; 4: Directly declare the risk-free version. 4. The method for automatically repairing Java software dependency conflict problems according to claim 3, characterized in that the process of selecting different strategies according to risk types to load risk-free versions into the current project is as follows: Step 4.1: After obtaining the risk-free version, determine the type of risk dependency conflict. If it is a conflict with direct dependencies, use strategies 1 and 2 in the repair strategy to replace the version and generate a temporary repair patch; if it is a conflict with no direct dependencies, If there is a conflict, use strategies 2, 3, and 4 to perform version replacement and generate a temporary repair patch; Step 4.2: For repair patches corresponding to different replacement strategies, analyze the dependencies after replacement and obtain the loaded version after current conflict replacement. If the risk-free version is loaded correctly, the replacement is successful; if the risk-free version is not loaded correctly, the replacement fails. , delete the temporary repair patch corresponding to the failed replacement strategy. 5. The method for automatically repairing Java software dependency conflict problems according to claim 1, characterized in that the process of step 5 is as follows: Step 5.1: Traverse all temporary repair patches in sequence and obtain the dependencies generated by the temporary repair patches; Step 5.2: Compare the new dependencies generated by the patch with the original dependencies of the project to see if there is a dependency conflict that is different from the original project. If so, go to the next step; if not, go to step 5.4; Step 5.3: Comparatively analyze the classes and methods in the loaded version and the unloaded version jar package. If a method in the unloaded version jar package does not have a corresponding method with the same qualified name in the loaded version jar package, it is a risky method. Obtain such a method collection and determine whether the methods in the collection are called in the current project. If there are calls, the repair patch will be invalid; if there are no calls, go to the next step; Step 5.4: Back up the successfully evaluated temporary repair patch to the user-specified folder.