CN117313088A - Java program dead code detection method based on abstract syntax tree and iteration - Google Patents
Java program dead code detection method based on abstract syntax tree and iteration Download PDFInfo
- Publication number
- CN117313088A CN117313088A CN202311248683.8A CN202311248683A CN117313088A CN 117313088 A CN117313088 A CN 117313088A CN 202311248683 A CN202311248683 A CN 202311248683A CN 117313088 A CN117313088 A CN 117313088A
- Authority
- CN
- China
- Prior art keywords
- methods
- java
- dead
- name
- list
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000001514 detection method Methods 0.000 title claims abstract description 41
- 238000000034 method Methods 0.000 claims abstract description 293
- 238000004140 cleaning Methods 0.000 claims abstract description 4
- 230000008676 import Effects 0.000 claims description 23
- 230000008569 process Effects 0.000 abstract description 2
- 238000004458 analytical method Methods 0.000 description 14
- 230000003068 static effect Effects 0.000 description 7
- 238000002474 experimental method Methods 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 3
- 238000002679 ablation Methods 0.000 description 1
- FFBHFFJDDLITSX-UHFFFAOYSA-N benzyl N-[2-hydroxy-4-(3-oxomorpholin-4-yl)phenyl]carbamate Chemical compound OC1=C(NC(=O)OCC2=CC=CC=C2)C=CC(=C1)N1CCOCC1=O FFBHFFJDDLITSX-UHFFFAOYSA-N 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/55—Detecting local intrusion or implementing counter-measures
- G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
- G06F21/562—Static detection
- G06F21/563—Static detection by source code analysis
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Health & Medical Sciences (AREA)
- General Health & Medical Sciences (AREA)
- Virology (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
The invention relates to a Java program dead code detection method based on an abstract syntax tree and iteration, which is a process for analyzing Java item codes through the abstract syntax tree and determining dead methods in the Java item codes. The concrete steps include cleaning items, obtaining abstract syntax trees, obtaining method call information and reference information, determining dead methods and the like. When the abstract syntax tree is obtained, a Java Parser tool is needed to obtain a complete path name list and related information of the method through traversing nodes. And then iteratively determining the dead method according to the calling relation among the methods. The end result is a dead set of methods. The method can solve the detection of dead methods in the project with method overwriting and reloading, the detection of dead methods in the project with multi-thread programming and the detection of dead methods in the project with cross-file method calling. Meanwhile, the method has good timeliness.
Description
Technical Field
The invention belongs to the field of static code analysis, relates to detection of a code peculiar smell, namely dead code, in Java codes, and mainly relates to a method-level Java program dead code detection technology based on an abstract syntax tree and iteration.
Background
There are a number of techniques for dead code detection, some of the main techniques including: (1) static code analysis: static code splitting is by analyzing the source code without requiring actual code transport to detect the code. It can identify problems with unused variables, unreachable code blocks, and inaccessible code. (2) code coverage tool: the code coverage tool is used to determine whether the test suite covers all paths in the code. By analyzing coverage information during code execution, non-executed code segments can be found. (3) dynamic runtime analysis: dynamic runtime analysis is to collect data and analyze it while actually running code, and detect dead code. Such a method may capture conditional branching and function call information during actual execution to determine which code is reachable or unexecuted.
The above-mentioned technology mainly has the following disadvantages: (1) false alarm and missing report: the dead code detection tool may generate false positives, i.e. the code that is actually reachable is marked as dead code, or false negatives, i.e. the dead code is not correctly identified. This may lead to developers spending time and effort handling false alarms or ignoring true dead code. (2) complexity and performance overhead: some dead code detection techniques require a face analysis of the entire code library, which can result in long analysis times and significant computational resource consumption. This can be a problem, especially for large projects or complex code libraries. (3) limitations of dynamic runtime analysis: dynamic runtime analysis requires critical running code, which may not capture all execution paths, especially under certain special conditions. Possibly resulting in a dead code not being detected. (4) dependencies and external calls: modern software typically involves multiple modules and external dependencies. Dead code detection is made more complex because the reachability of code may be affected by part calls and dependencies. Current technology may have certain limitations in dealing with this situation.
The subdivision domain to the detection of dead code at the method level using means of static code analysis for Java programs also faces some of these more specific problems. (1) multithreading: multithreading is enabled using Java, and to execute a thread, a start () method is first called to transition the thread from a "new state" to a "ready state", and then run () is executed to acquire CPU resources, thereby transitioning the thread from the "ready state" to the "running state". The run () method is however a system dispatch, transparent to the programmer, and is not explicitly invoked in Java programs, but is actually run. The run () method in multi-threaded programming cannot be treated as a dead method at dead method detection. (2) overwriting and reloading of the method: problems of overwriting and reloading of methods can be involved in object-oriented programming. The overwriting refers to a method that a child can overwrite a parent, one overwriting generates two methods with identical names, parameters and return types, and in the detection of a dead method, a method which needs to be identified as being the child or the parent is called. The reloading means that a plurality of methods with the same names appear in the same class, but the shape parameter list is different, and in the detection of the dead method, it is required to determine which reloading method is called according to different parameter types. (3) identifying a dead method across files: most of existing dead method detection tools based on static code analysis cannot solve detection of a dead method across files, and cannot realize detection of the dead method across files due to lack of understanding of project structures, limitation of input formats and the like. (4) complexity and performance overhead: detection of dead code requires scanning all code of the item, which may result in long analysis times and significant computational resource consumption. Especially for large projects or complex code libraries.
Disclosure of Invention
Aiming at the problems existing in the prior art, the invention aims to solve the technical problems that: there are technical problems of how to detect dead methods in items that are overwritten and reloaded by methods, how to detect dead methods in items that are multithreaded programmed, and how to detect dead methods in items that are called by methods across files.
In order to solve the technical problems, the invention adopts the following technical scheme: a Java program dead code detection method based on abstract syntax tree and iteration comprises the following steps:
s101: inputting a Java item in a zip format, cleaning the item to obtain a file only containing the Java format, and reserving a directory structure of the Java item.
S102: and acquiring abstract syntax trees corresponding to each Java-format file in the project through a Java Parser tool for the cleaned file.
S103: traversing the nodes of the abstract syntax tree obtained in the S102 to obtain a complete path name list fullMet of all methods in the Java item; obtaining a method name and an import list of the class of the method, and storing the method name and the import list by using a hash map, wherein the method name and the import list are denoted as met odAndItsImports; obtaining a method name and location information of the method, and storing the method name and the location information by using a hash map, wherein the method name and the location information are denoted as met odAndItsPosition; obtaining class names and types of variables in the classes, and storing the class names and the types of the variables in the classes by using a hash map, wherein the class names and the types of the variables in the classes are expressed as classArguentType; obtaining a method name and a called method of the method, using a hash map store, denoted met odCallsWit Callee; a list entiyofprogram of all entry methods is obtained.
S104: the dead methods were recorded by defining the same list deadMet ods as the full pathname list fullMet ods for all methods.
S105: a stack S is defined, and all methods in the entiOfProgram are pushed to the stack by the initial state.
S106: whether the stack S is empty is determined, S107 is executed if the stack S is not empty, and S112 is executed if the stack S is empty.
S107: and (3) popping the stack top element in the stack S, namely the method m, and deleting m in the desadMetod of the method.
S108: obtaining an import list imports of the class of the method m from met odAmdItsImports; the set setofCalle of all methods called by method m is obtained from met odCallsWit Callee, which can only simply obtain the method name of the called method, but cannot obtain the method name of the complete path.
S109: for all methods c in the steofCalle, determining whether c matches the method name f in the fullMet ods cyclically, and if so, adding c into a predefined set sameNames.
S110: judging the number of elements in the set sameNames, if the number is equal to 1, pushing c into a stack S, and deleting c in the deadMetods of the method; if the number is greater than 1, S111 is executed.
S111: comparing all the method S in the sameNames with all the elements in the imports list acquired in the step S108, if S is matched with the elements in the imports list, pushing S to the stack S, and deleting S in the deadMetods of the method; if no element in the lists of ports is found to match S, then S106 is performed.
S112: and (5) after the iteration is finished, obtaining a dead method set deadMetod.
Preferably, the step S103 includes the following specific steps:
when the fullMet os is acquired, the Java Parser tool acquires the method name n of the method, which is a method name without the method path information and the parameter type information. The parameter type information of the method is complemented by analyzing the information of the method nodes in the abstract syntax tree, so that the method name n with the parameter type information is obtained arg Then parsing the path of Java item to obtain complete path of method, thereby obtaining method name with parameter type information and complete pathAll ofA complete pathname list fullMet ods of all methods in the Java project is constituted.
When met odCallsWit Callee is obtained, the Java Parser tool can only obtain the method name of the called method, find the type corresponding to the parameter in the classArgementType, and then fill the type information of the parameter into the back of the method name of the called method, so that the method name with the path information and the parameter type information of the key can be obtained, and the value is the hash map of the called method set with the parameter type.
Preferably, the step S109 includes the following steps when determining whether c and f match: firstly judging whether the names of the methods are consistent, if so, judging whether the numbers of the parameters are equal, if so, judging whether the types of the parameters are consistent in sequence, if the judgment is successful, matching c and f is successful, otherwise, if one judgment is unsuccessful, the matching is failed.
Compared with the prior art, the invention has at least the following advantages:
1. the method and the device determine whether the called method belongs to the subclass or the parent class and are easy to be confused after determining that the method is rewritten by acquiring the complete path of the method and the information of the class or the interface and the like to which the method belongs. And by acquiring the parameter information of the method, the problem that the method which is the only method to be called is easy to be confused is solved. In the dead method detection process, the polymorphism characteristics of object-oriented programming are taken into consideration, so that the accuracy and the expandability of the method are improved.
2. The method and the device set rules for the run () method by identifying the information of the class or interface of the multithread programming, namely the run () method is necessarily called in the default multithread programming, so that the problem that the method directly or indirectly called by the run () method is wrongly identified as a dead method due to the implicit calling of the run () method in the multithread programming scene is solved. At present, java multi-thread programming is widely used, particularly in a high concurrency scene, so that the accuracy of dead code identification can be improved by solving the problem of implicit call identification in multi-thread programming. The method and the device acquire the report list of the class of the method and use the report list as an interface for communicating files, so that the method call of the cross-file is acquired, and a more complete method call graph is constructed. The method solves the problem that the accuracy of dead method detection can be improved by constructing a cross-file call graph. Meanwhile, the invention has good timeliness.
Drawings
FIG. 1 shows an example of Java multithreading.
Fig. 2 shows an example of overwriting and reloading.
FIG. 3 is a comparison of experimental effects (based on accuracy, recall and F1 values).
Fig. 4 is a flow chart of the method of the present invention.
Detailed Description
The present invention will be described in further detail below.
The method adopts an open source tool Java Parser to acquire the abstract syntax tree, acquires the call information of the method and the reference information among the files from the nodes of the abstract syntax tree, and acquires the call relation among the methods based on the information, thereby iteratively determining dead methods.
A Java program dead code detection method based on abstract syntax tree and iteration comprises the following steps:
s101: inputting a Java item in a zip format, cleaning the item to obtain a file only containing the Java format, and reserving a directory structure of the Java item;
s102: the method comprises the steps that for cleaned files (only files in Java format are contained in Java items), abstract syntax trees corresponding to the files in Java format in the items are obtained through a Java Parser tool;
s103: traversing the nodes of the abstract syntax tree obtained in the S102 to obtain a complete path name list fullMet of all methods in the Java item; obtaining a method name and an import list of the class of the method, and storing the method name and the import list by using a hash map, wherein the method name and the import list are denoted as met odAndItsImports; obtaining a method name and location information of the method, and storing the method name and the location information by using a hash map, wherein the method name and the location information are denoted as met odAndItsPosition; obtaining class names and types of variables in the classes, and storing the class names and the types of the variables in the classes by using a hash map, wherein the class names and the types of the variables in the classes are expressed as classArguentType; obtaining a method name and a called method of the method, using a hash map store, denoted met odCallsWit Calee; obtaining a list entiyofprogram of all the entry methods (i.e., the main methods);
s104: defining a list deadMet ods identical to a full pathname list fullMet ods for all methods to record dead methods;
s105: defining a stack S, and pushing all methods in the entiOfProgram to the stack in an initial state;
s106: judging whether the stack S is empty or not, executing S107 if the stack S is not empty, and executing S112 if the stack S is empty;
s107: the stack top element in the stack S, namely a method m, is popped off, and m is deleted in the readMetods of the method;
s108: obtaining an import list imports of the class of the method m from met odAndItsImports; acquiring a set setofCalle of all methods called by the method m from met odCallsWit Callee, wherein the set can only simply acquire the method name of the called method, but cannot acquire the method name of the complete path;
s109: for all methods c in setofCalle, circularly judging whether c is matched with a method name f in fullMet ods, if so, adding c into a predefined set sameNames;
s110: judging the number of elements in the set sameNames, if the number is equal to 1, pushing c into a stack S, and deleting c in the deadMetods of the method; if the number is greater than 1, executing S111;
s111: comparing all the method S in the sameNames with all the elements in the imports list acquired in the step S108, if S is matched with the elements in the imports list, pushing S to the stack S, and deleting S in the deadMetods of the method; if no element in the lists of the ports is found to match S, then S106 is executed;
s112: after iteration is finished, a dead method set deadMetod is obtained;
specifically, the step S103 includes the following specific steps:
when the fullMet os is acquired, the Java Parser tool acquires the method name n of the method, which is a method name without the method path information and the parameter type information. The parameter type information of the method is complemented by analyzing the information of the method nodes in the abstract syntax tree, so that the method name n with the parameter type information is obtained arg Then parsing the path of Java item to obtain complete path of method, thereby obtaining method name with parameter type information and complete pathAll ofA complete pathname list fullMet os that constitutes all methods in the Java project;
when met odCallsWit Callee is obtained, the Java Parser tool can only obtain the method name of the called method, and needs to parse the method nodes in the abstract syntax tree to obtain the actual parameters of the method, however, we can only obtain the actual parameters but cannot directly obtain the parameter types. At this time, the type corresponding to the parameter needs to be searched in the classArgementType, and then the type information of the parameter is filled behind the method name of the called method, so that the hash map that the key is the method name with the path information and the parameter type information and the value is the called method set with the parameter type can be obtained.
Specifically, the method c in setofCalle in S109 is just a method name and a method parameter, and f has parameter type information and a complete path, and when judging whether c and f match, the method includes the following steps: firstly judging whether the names of the methods are consistent, if so, judging whether the numbers of the parameters are equal, if so, judging whether the types of the parameters are consistent in sequence, if the judgment is successful, matching c and f is successful, otherwise, if one judgment is unsuccessful, the matching is failed.
Experiment:
(1) Implicit invocation of run () method in multi-threaded programming
When Java is used for multithreading programming, a thread can be converted from a new state to a ready state by calling a start () method, and then a system can automatically schedule a run () method for executing the thread to convert the thread from the ready state to a running state so as to acquire CPU resources. Although the run () method is not explicitly called in the Java program, it is actually scheduled and executed by the system. Therefore, when deadlock detection is performed, we cannot consider the run () method in multi-threaded programming as a dead method. In the invention, the run () method in the class inheriting the Thread class or realizing the Ruable interface is actively marked as a live method, thereby solving the problem of implicit calling of the run () method.
(2) Detection of dead methods in items where there is reloading and overwriting of methods
In object-oriented programming, problems of overwriting and reloading of methods are involved. Overwriting refers to a method by which a child can overwrite a parent, such that one overwrite results in two identical methods, including a method name, a parameter, and a return type. We need to identify whether the method that is the child or parent is called. The reloading refers to a method that multiple methods with the same name but different shape parameter list appear in the same class. When making a call to a method, we need to determine which reload method is called at all, based on different parameter types. The present invention gives a solution to the problem of overwriting by using the full path name of the method to represent the method. For example, fig. 2 contains a method of real, and the subclass Dog contains a method of real, dog, and this means that the method in the parent class and the method of overwriting in the corresponding subclass can be uniquely identified. For the problem of reloading, the solution of the invention is to use the information of the parameters of the method to uniquely identify the reloading method. For example: dog. Move (int) and Dog. Move (intelger).
(3) Detection of dead methods with cross-file calls
Because of lack of understanding of project structure and input format, and other limitations, most existing dead method detection tools based on static code analysis are unable to effectively solve the problem of dead method detection across files. The solution to this problem is to use the lists of the imports of each Java file as an interface for its communication with other files. When a method belonging to other files is judged, determining the attribution problem of the method through the lists of the imports.
(4) Complexity and performance overhead
Dead code detection techniques require a face analysis of the entire code library, which can result in long analysis times and significant computational resource consumption. Especially for large projects or complex code libraries. The time complexity of the core algorithm of the invention is O (|fullmethods|), which is the set of all methods in Java project. When solving the practical problem, the method has higher timeliness.
2. Experiment
In our experiments, we need to evaluate the following properties:
correctness: reflects whether the method regarded as the dead method is a dead method or not;
integrity: reflecting whether a set of methods considered dead methods is complete relative to the actual total number of dead methods;
accuracy: reflecting correctness and integrity.
The evaluation indexes are accuracy, recall, and F1-score. Accuracy is based on the formulaCalculating recall is based on the formula->The calculation TP (True Positives) is a method set that correctly detects as a dead method, FP (False Positive) is a method set that incorrectly detects as a dead method, and FN (False Negatives) is a dead method set that cannot be detected as a dead method. The F1 value is based on the formulaWhere Pre and Re are abbreviations for accuracy Precision and Recall, respectively, which represent a tradeoff in the accuracy and completeness of the results. Accuracy Precision, recall, and F1-score are located in intervals of [0,1]Where 1 is the optimum. The higher the accuracy Precision, the more accurate the result of dead method detection, the higher the Recall ratio Recall, the more complete the result of dead method detection, and the higher the F1 score, the more accurate the result of dead method detection.
Two Java items (PROJECT 1 and PROJECT 2) were selected as subjects. As shown in Table 1, PROJECT1 has a total code line number of 2472 lines, containing 236 methods, and by way of artificial markers, PROJECT1 is known to contain 66 dead methods. Total code behavior for PROJECT2, line 7936, contains 671 methods, and by way of artificial markers, PROJECT2 is known to contain 208 dead methods.
TABLE 1
To verify whether the present invention effectively solves the above problems, we define three rules to perform ablation experiments:
rule1: the detection of dead methods in the items of overwriting and reloading of existing methods can be solved;
rule2: the detection of dead methods in the project with multi-thread programming can be solved;
rule3: rules for detecting dead methods in items with cross-file method calls can be solved;
as shown in fig. 3, for the process 1, in the experimental results with Rule1 only and Rule1& Rule2 only, the accuracy Precision and the F1 value are both relatively low, and after Rule3 is added, the accuracy Precision and the F1 value are both ninety-one or more. Similarly, for PROJECT2, after Rule1& Rule2& Rule3 is provided, both accuracy and F1 values are greatly improved. Regardless of whether for PROJECT1 or PROJECT2, recall is above ninety percent, which illustrates that the present invention performs relatively well in the integrity of dead-method detection. It is worth mentioning that the timeliness of the present invention is also perceived as good, and the detection time of the dead method of the present invention is 1.294s and 2.836s for PROJECT1 and PROJECT2, respectively.
In short, the invention provides a method for detecting dead methods in Java static codes based on an abstract syntax tree. The method can solve the detection of dead methods in the project with method overwriting and reloading, the detection of dead methods in the project with multi-thread programming and the detection of dead methods in the project with cross-file method calling. Meanwhile, the method has good timeliness.
Finally, it is noted that the above embodiments are only for illustrating the technical solution of the present invention and not for limiting the same, and although the present invention has been described in detail with reference to the preferred embodiments, it should be understood by those skilled in the art that modifications and equivalents may be made thereto without departing from the spirit and scope of the technical solution of the present invention, which is intended to be covered by the scope of the claims of the present invention.
Claims (3)
1. A Java program dead code detection method based on abstract syntax tree and iteration is characterized by comprising the following steps:
s101: inputting a Java item in a zip format, cleaning the item to obtain a file only containing the Java format, and reserving a directory structure of the Java item;
s102: obtaining abstract syntax trees corresponding to each Java-format file in the project through a Java Parser tool for the cleaned files;
s103: traversing the nodes of the abstract syntax tree obtained in the S102 to obtain a complete path name list fullMet of all methods in the Java item; obtaining a method name and an import list of the class of the method, and storing the method name and the import list by using a hash map, wherein the method name and the import list are denoted as met odAndItsImports; obtaining a method name and location information of the method, and storing the method name and the location information by using a hash map, wherein the method name and the location information are denoted as met odAndItsPosition; obtaining class names and types of variables in the classes, and storing the class names and the types of the variables in the classes by using a hash map, wherein the class names and the types of the variables in the classes are expressed as classArguentType; obtaining a method name and a called method of the method, using a hash map store, denoted met odCallsWit Callee; obtaining a list entiyofprogram of all the entry methods;
s104: defining a list deadMet ods identical to a full pathname list fullMet ods for all methods to record dead methods;
s105: defining a stack S, and pushing all methods in the entiOfProgram to the stack in an initial state;
s106: judging whether the stack S is empty or not, executing S107 if the stack S is not empty, and executing S112 if the stack S is empty;
s107: the stack top element in the stack S, namely a method m, is popped off, and m is deleted in the desadMetod of the method;
s108: obtaining an import list imports of the class of the method m from met odAndItsImports; acquiring a set setofCalle of all methods called by the method m from met odCallsWit Callee, wherein the set can only simply acquire the method name of the called method, but cannot acquire the method name of the complete path;
s109: for all methods c in setofCalle, circularly judging whether c is matched with a method name f in fullMet ods, if so, adding c into a predefined set sameNames;
s110: judging the number of elements in the set sameNames, if the number is equal to 1, pushing c into a stack S, and deleting c in the deadMetods of the method; if the number is greater than 1, executing S111;
s111: comparing all the method S in the sameNames with all the elements in the imports list acquired in the step S108, if S is matched with the elements in the imports list, pushing S to the stack S, and deleting S in the deadMetods of the method; if no element in the lists of the ports is found to match S, then S106 is executed;
s112: and (5) after the iteration is finished, obtaining a dead method set deadMetod.
2. The Java program dead code detecting method based on abstract syntax tree and iteration as claimed in claim 1, wherein: the step S103 comprises the following specific steps:
when the fullMet os is acquired, the Java Parser tool acquires the method name n of the method, which is a method name without the method path information and the parameter type information. The parameter type information of the method is complemented by analyzing the information of the method nodes in the abstract syntax tree, so that the method name n with the parameter type information is obtained arg Then parsing the path of Java item to obtain complete path of method, thereby obtaining method name with parameter type information and complete pathAll->Complete path constituting all methods in Java itemThe name list fullMet ods;
when met odCallsWit Callee is obtained, the Java Parser tool can only obtain the method name of the called method, find the type corresponding to the parameter in the classArgementType, and then fill the type information of the parameter into the back of the method name of the called method, so that the method name with the path information and the parameter type information of the key can be obtained, and the value is the hash map of the called method set with the parameter type.
3. The Java program dead code detecting method based on abstract syntax tree and iteration as claimed in claim 2, wherein: the step S109 includes the following steps when determining whether c and f match: firstly judging whether the names of the methods are consistent, if so, judging whether the numbers of the parameters are equal, if so, judging whether the types of the parameters are consistent in sequence, if the judgment is successful, matching c and f is successful, otherwise, if one judgment is unsuccessful, the matching is failed.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311248683.8A CN117313088A (en) | 2023-09-26 | 2023-09-26 | Java program dead code detection method based on abstract syntax tree and iteration |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311248683.8A CN117313088A (en) | 2023-09-26 | 2023-09-26 | Java program dead code detection method based on abstract syntax tree and iteration |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117313088A true CN117313088A (en) | 2023-12-29 |
Family
ID=89249347
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311248683.8A Pending CN117313088A (en) | 2023-09-26 | 2023-09-26 | Java program dead code detection method based on abstract syntax tree and iteration |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117313088A (en) |
-
2023
- 2023-09-26 CN CN202311248683.8A patent/CN117313088A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Guo et al. | Characterizing and detecting resource leaks in Android applications | |
| US8434054B2 (en) | System and method for managing cross project dependencies at development time | |
| US7275239B2 (en) | Run-time wait tracing using byte code insertion | |
| CN105630463B (en) | For detecting the method and device of JAR packet conflict | |
| Petrović et al. | Practical mutation testing at scale: A view from google | |
| CN112965913B (en) | Java software dependency conflict problem automatic repairing method | |
| CN112799937B (en) | Method for automatically detecting dependence conflict problem in Maven project based on Github | |
| CN112181858B (en) | Automatic detection method for Java software project dependent conflict semantic consistency | |
| CN111737697B (en) | Safety scanning system and scanning method based on atomization function | |
| Horwitz et al. | Efficient comparison of program slices | |
| CN112860312A (en) | Method and device for detecting item dependency relationship change | |
| Souter et al. | Omen: A strategy for testing object-oriented software | |
| CN108897678B (en) | Static code detection method, static code detection system and storage device | |
| US11379251B2 (en) | Method for executing a computer program in a computer network, in particular in order to control a microscope | |
| CN117313088A (en) | Java program dead code detection method based on abstract syntax tree and iteration | |
| CN111352631A (en) | Interface compatibility detection method and device | |
| CN113127367B (en) | Defect detection method for Android dynamic permission application | |
| CN113626823B (en) | Method and device for detecting interaction threat among components based on reachability analysis | |
| Masud et al. | Automatic inference of task parallelism in task-graph-based actor models | |
| Flederer et al. | Source code verification for embedded systems using prolog | |
| CN114328168B (en) | Abnormality detection method, abnormality detection device, computer device, and storage medium | |
| CN110471669A (en) | A kind of detection method and detection device of null pointer dereference | |
| CN117131236B (en) | Sensitive data detection method and system | |
| CN113296834B (en) | Android closed source service type information extraction method based on reverse engineering | |
| Norlén | Architecture for a Symbolic Execution Environment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |