# Automatic Refactoring Approach for Asynchronous Mechanisms with CompletableFuture
## 6 Implementation and Evaluation
### Results and Analysis
This increase was due to the need to add code to ensure that exception handling within Callable was unaffected by Refactoring Pattern 2, as well as the introduction of new types into the source files during refactoring. In the Hadoop \begin{table}
\begin{tabular}{c c c c c c} \hline \hline \multirow{2}{*}{**Project Name**} & \multirow{2}{*}{**Variable Type Casting**} & \multicolumn{2}{c}{**Variable Declaration**} & \multirow{2}{*}{**Executor Type Mismatch**} & \multirow{2}{*}{**Cancel (True)**} & \multirow{2}{*}{**Total**} \\  & & & **Type Not Future** & & & \\ \hline ActiveMQ & 0 & 0 & 11 & 4 & 15 \\ Hadoop & 0 & 10 & 40 & 37 & 87 \\ Elasticsearch & 0 & 0 & 3 & 0 & 3 \\ Jenkins & 10 & 0 & 25 & 0 & 35 \\ JGroups & 3 & 7 & 10 & 0 & 20 \\ Tomcat & 3 & 0 & 6 & 1 & 10 \\ Flume & 0 & 0 & 10 & 0 & 10 \\ ZooKeeper & 0 & 0 & 2 & 3 & 5 \\ Tika & 0 & 0 & 0 & 0 & 0 \\ total & 16 & 17 & 107 & 45 & 185 \\ \hline \hline \end{tabular}
\end{table} 
Table 9: Statistics on Reasons for submit Refactoring Failures. program, given that it had the highest number of Refactoring Pattern 2 applications, it also showed the greatest change in lines of code, increasing by 726 lines. On the other hand, in Elasticsearch and JGroups, where there were no instances of Refactoring Pattern 2 and the refactoring was more concentrated within code files, the change in lines of code was minimal. As illustrated in Table 11, the time consumed by ReFuture for refactoring is broken down into the time for building program call graphs and the time for code refactoring. Hadoop, having the highest number of Java lines, also had the longest refactoring time at 2621 s. ReFuture conducts refactoring at the Eclipse project level, and programs managed with Maven often contain multiple submodules, each represented as a project in Eclipse. Therefore, the refactoring tool needs to be run multiple times to complete refactoring tasks like in ActiveMQ, which significantly contributed to the longer duration consumed for Hadoop and ActiveMQ. Flume, ZooKeeper, and Tika required 415, 284, and 261 s, respectively, to complete refactoring. Although these are also managed using Maven, they have fewer lines of code and contain fewer traditional asynchronous constructs. For instance, in the ZooKeeper test program, only the zookeeper-serve submodule exists in traditional asynchronous constructs, and ReFuture skips building the call graph, saving time. ReFuture refactored 639 traditional asynchronous constructs, adding a total of 1592 lines of code, an average increase of 2.49 lines per instance, indicating low invasiveness. This suggests that our refactoring has minimal impact on the programs beyond achieving the set objectives. Most of the time consumed was spent on building the full program call graphs. The total refactoring time for the nine test programs was 9520 s, with an average of 1057.78 s per test program. * RQ4: How does ReFuture compare to existing methods for refactoring traditional asynchronous constructs? \begin{table}
\begin{tabular}{c c c c} \hline \hline
**Project** & **Code Lines Before Refactoring** & **Code Lines After Refactoring** & **Code Lines Modified by Refactoring** \\ \hline ActiveMQ & 532,567 & 532,965 & 398 \\ Hadoop & 1,398,914 & 1,399,640 & 726 \\ Elasticsearch & 704,199 & 704,238 & 39 \\ Jenkins & 188,273 & 188,361 & 88 \\ JGroups & 126,110 & 126,139 & 29 \\ Tomcat & 357,202 & 357,298 & 96 \\ Flume & 94,180 & 94,234 & 54 \\ ZooKeeper & 127,087 & 127,170 & 83 \\ Tika & 164,885 & 164,964 & 79 \\ total & 3,693,417 & 3,695,009 & 1592 \\ \hline \hline \end{tabular}
\end{table} 
Table 10: Code Line Changes Before and After ReFuture Refactoring.