# Automatic Refactoring Approach for Asynchronous Mechanisms with CompletableFuture
## 4 Empirical Research
### Executor Inheritance Structure Analysis  
The JUC package contains 3 delegated executor types. Our source code review indicates that other executor types are also refactorable. However, software projects may use executor types from third-party libraries or custom-implemented executor types, the latter of which often appear in software projects that heavily utilize asynchronous programming techniques. For example, Jenkins has 6 custom executor types, while the JUC package has only 3 delegated types and 4 other executor types. The refactoring method mentioned in previous research [4] does not apply to subclassed asynchronous constructs, which means that the more widely asynchronous programming is used in a project, the more likely it is that the project cannot be fully refactored. Therefore, we propose an executor inheritance structure analysis method. Starting from the two most common object-oriented code reuse mechanisms of inheritance and delegation [27], we perform static analysis on the entire executor inheritance structure of the software project to obtain all the executor types that can be refactored, as well as the executor types that need further judgment due to the use of the delegation pattern. Finally, we exclude all executor types that have type checks and type casts in their'submit' and 'execute' methods, as these executor types cannot be safely refactored.  
Our static analysis method is based on points-to analysis, and we begin by defining points-to analysis.  
Definition 1: Points-to analysis: points-to analysis is a static program analysis technique that computes the memory locations that references in a program can point to at runtime [28]. It is formally represented as:\[\text{pointsTo}(ref)=\{i_{1},i_{2},\ldots,i_{n}\} \tag{1}\]  
Here, \"_ref_\" is a reference type variable, \(i_{k}\in\{i_{1},i_{2},\ldots,i_{n}\}\) (\(1\leq k\leq n\)) is an abstract heap object identifier. We use the flow-insensitive, interprocedural context-insensitive points- to analysis provided by the Spark static analysis framework [29] in Soot. This points-to analysis maps object creation statements in the program (new statements) to corresponding abstract heap object identifiers.  
**Definition 2**.: _Alias analysis: alias analysis is a static analysis technique used to determine whether two or more references might refer to the same memory location. It is a variant of points-to analysis, formally represented as [30]:_  
\[\text{alias}(ref_{1},ref_{2})=\left\{\begin{array}{ll}\text{true}&\text{if pointsTo}(ref_{1})\cap\text{pointsTo}(ref_{2})\
eq\varnothing\\ \text{false}&\text{otherwise}\end{array}\right. \tag{2}\]  
**Definition 3**.: _possibleTypes: Soot provides a method to obtain the possible actual types of reference variables through the results of points-to analysis, represented by abstract heap object identifiers (new statements). It is formally represented as:_  
\[\text{possibleTypes}(ref)=\{T|\ T\in\text{getType}(\text{pointsTo}(ref))\} \tag{3}\]  
Here, \"getType\" is used to obtain the type information of an abstract heap object identifier (new statement).