# Automatic Refactoring Approach for Asynchronous Mechanisms with CompletableFuture
## 6 Implementation and Evaluation
### Results and Analysis  
* RQ1: How many instances can ReFuture refactor in real projects? To address the research questions, we assessed the success and failure counts of ReFuture's refactoring across the four patterns and analyzed the reasons for any failures. Since the preconditions for refactoring execute and submit methods differ, the results are presented in two parts, as shown in Tables 7 and 8. \begin{table}
\begin{tabular}{c c c c c c} \hline \hline
**Project Name** & **Version** & \
\begin{tabular}{c} **Number of Traditional** \\ **Asynchronous Constructs** \\ \end{tabular} & **Number of Execute** & **Number of Submit** &
\begin{tabular}{c} **Number of Lines** \\ **of Java Code** \\ \end{tabular} \\ \hline ActiveMQ & 5.16.6 & 345 & 273 & 72 & 532,567 \\ Hadoop & 2.10.2 & 170 & 43 & 127 & 1,398,914 \\ Elasticsearch & 6.14 & 103 & 97 & 6 & 704,199 \\ Jenkins & 2.356 & 52 & 4 & 48 & 1,195,314 \\ JGroups & 4.2.21 & 47 & 26 & 21 & 126,110 \\ Tomcat & 9.0.80 & 46 & 33 & 13 & 357,202 \\ Flume & 1.10.1 & 22 & 2 & 20 & 94,180 \\ ZooKeeper & 3.8.0 & 19 & 4 & 15 & 127,087 \\ Tika & 2.8.0 & 9 & 4 & 5 & 164,885 \\ total & — & 813 & 486 & 327 & 4,700,458 \\ \hline \hline \end{tabular}
\end{table} 
Table 6: Test Program Information. Table 7 summarizes the refactoring results for the execute method across nine test programs. Out of 486 execute nodes, 384 were successfully refactored. The projects Hadoop, Flume, ZooKeeper, and Tika achieved complete success in their refactoring efforts. In contrast, other projects faced cancellations due to incompatible executor types. Notably, ActiveMQ, being a message middleware program, had the highest number of nodes requiring refactoring. Elasticsearch followed with the second highest number of nodes, with 70 instances canceled due to executor type mismatches. Table 8 presents the results for the three submit method refactoring patterns. Refactoring submit methods is more complex and has stricter conditions compared to execute, resulting in 142 successful refactorings out of 327 asynchronous task submission nodes. Elasticsearch, Flume, ZooKeeper, and Tika included only patterns 2 and 3, while Tomcat had instances of all 3 patterns. Among the 3 patterns, pattern 4 had the fewest refactorings due to the lower number of submit(Runnable, Value) calls--only 4 instances across the 9 test programs. Refactoring successes were further enhanced by delegating analysis to help determine executor types, leading to 26 additional successful refactorings in ActiveMQ, Hadoop, Jenkins, Tomcat, and ZooKeeper. This approach increased the number of successful refactorings by 22.4% compared to without using delegation analysis. Table 9 provides a detailed breakdown of the reasons for refactoring failures across the three submit method patterns. Out of 327 submit method invocations, 185 potential refactorings were excluded. The primary reason for exclusion was incompatible executor types, accounting for 107 cases. This issue was prevalent across multiple test programs, with Tika being the only program without this issue. The second major reason was the presence of cancel(true) method invocations, found in 45 cases. Additional issues included type cast mismatches and declaration type mismatches, with 16 and 17 occurrences, respectively. Unlike incompatible executor types, these issues were more localized to specific test programs. \begin{table}
\begin{tabular}{c c c} \hline \hline
**Project Name** & **Number of Execute** & **Number of Refactorings for Pattern 1** & **Executor Type Mismatch** \\ \hline ActiveMQ & 273 & 270 & 3 \\ Hadoop & 43 & 43 & 0 \\ Elasticsearch & 97 & 27 & 70 \\ Jenkins & 4 & 3 & 1 \\ JGroups & 26 & 19 & 7 \\ Tomcat & 33 & 12 & 21 \\ Flume & 2 & 2 & 0 \\ ZooKeeper & 4 & 4 & 0 \\ Tika & 4 & 4 & 0 \\ total & 486 & 384 & 102 \\ \hline \hline \end{tabular}
\end{table} 
Table 7: Statistics on execute Refactoring Outcomes.