# Automatic Refactoring Approach for Asynchronous Mechanisms with CompletableFuture
## 6 Implementation and Evaluation
### Results and Analysis
\begin{table}
\begin{tabular}{c c c c c c c c c c} \hline \hline \multirow{2}{*}{**Project Name**} & \multicolumn{4}{c}{**Number of Submit**} & \multicolumn{4}{c}{**Number of Refactorings**} & \multicolumn{2}{c}{**Results Obtained from**} \\ \cline{2-10}  & **Pattern 2** & **Pattern 3** & **Pattern4** & **Total** & **Pattern 2** & **Pattern 3** & **Pattern 4** & **Total** & **Delegation Analysis** \\ \hline ActiveMQ & 13 & 1 & 58 & 72 & 10 & 0 & 47 & 57 & 7 \\ Hadoop & 102 & 0 & 25 & 127 & 33 & 0 & 7 & 40 & 5 \\ Elasticsearch & 1 & 0 & 5 & 6 & 1 & 0 & 2 & 3 & 0 \\ Jenkins & 23 & 2 & 23 & 48 & 5 & 0 & 8 & 13 & 10 \\ JGroups & 15 & 1 & 5 & 21 & 0 & 0 & 1 & 1 & 0 \\ Tomcat & 3 & 1 & 9 & 13 & 0 & 0 & 3 & 3 & 2 \\ Flume & 2 & 0 & 18 & 20 & 2 & 0 & 8 & 10 & 0 \\ ZooKeeper & 5 & 0 & 10 & 15 & 1 & 0 & 9 & 10 & 2 \\ Tika & 2 & 0 & 3 & 5 & 2 & 0 & 3 & 5 & 0 \\ total & 166 & 5 & 156 & 327 & 54 & 0 & 88 & 142 & 26 \\ \hline \hline \end{tabular}
\end{table} 
Table 8: Statistics on submit Refactoring Outcomes. Overall, ReFuture successfully refactored 639 out of 813 traditional asynchronous constructs in the nine test programs, achieving a refactoring success rate of 64.70%. * RQ2: Does ReFuture introduce errors into the code after refactoring? Verification of the correctness of the refactorings was divided into two layers: syntactic and semantic correctness. On the syntactic level, all refactored code could be compiled without errors. Semantically, similar to the assumptions in the literature [4], we presumed that if unit tests passed both before and after refactoring, the refactorings did not alter the functionality of the code, thus preserving the correct program semantics. Although the nine test programs selected are well-known open-source projects with mature test suites, there were still issues: 1. Some tests could not pass even before refactoring the original code, and 2. Some refactored code was not covered by existing test cases. To address these issues, we used Randoop to generate supplementary test cases. Specifically, we first used automated tools to generate a list of methods affected by the refactorings in the test programs, not only the methods containing the refactored code but also methods calling the refactored methods, as determined by call graphs. We then excluded inaccessible methods, such as those declared private. Subsequently, Randoop was used to generate test cases for the methods in the list. Randoop automatically identifies methods that might have side effects (e.g., writing/reading files), leading to potentially different outcomes with each call; therefore, we discarded the test cases it generated for such methods and removed all test cases that failed. Finally, we retained all the Randoop-generated test cases that passed. We combined the retained Randoop-generated test cases with those provided by the test programs that could pass the tests to form the final test suite. After executing the refactoring with ReFuture, we ran the final test suite and found no new test errors, confirming that our refactorings did not affect the semantic correctness of the program. * RQ3: How much code does ReFuture need to change and how much time does it take to complete the refactoring? To address this question, we evaluated the efficiency of our automated refactoring method as well as the invasiveness of the refactoring on the code. Invasiveness refers to the impact of our refactoring on the refactored programs while achieving the set objectives; excessive invasiveness can increase the difficulty of understanding the code and reduce its maintainability. As shown in Table 10, we used the popular code counting tool SLOCCount to tally the lines of code before and after refactoring. The nine test programs together comprised 3,693,417 lines of Java code. After refactoring, the total number of lines increased to 3,695,009, an increase of 1,592 lines.