# Automatic Refactoring Approach for Asynchronous Mechanisms with CompletableFuture
## 2 Related Work
[PERSON] and colleagues [21] demonstrated that there is room for optimization in the ordering of asynchronous I/O operations in existing JavaScript code, using static side-effect analysis to refactor asynchronous I/O operations to enhance program performance. To better summarize the related work, as shown in Table 1, we present a comparison of studies on concurrency refactoring. In Table 1, we initially showcase the study by [PERSON] et al. [9] as it represents a significant work in the field of concurrency refactoring. This study aims to enhance code efficiency by automatically transforming sequential/synchronous code into concurrency/asynchronous code. Subsequently, the research by [PERSON] et al. [6; 7] focuses on refactoring concurrency programs that use outdated APIs to utilize updated APIs for code optimization. [PERSON] et al. 's study [8; 14] addresses both these aspects. The research by [PERSON] et al. [15] involves transforming synchronous APIs in JavaScript into asynchronous ones using the async/await keywords to boost performance. The constructs of the refactorings in the last three rows of the table are related to those in our study. The research by [PERSON] et al. [13] resulted in refactoring that utilizes the CompletableFuture construct to asynchronously execute the original synchronous code. [PERSON] et al. [4] conducted refactoring of both the SwingWorker and ExecutorService frameworks to support the RxJava reactive programming library, using RxJava's Observable to encapsulate the Future returned by traditional asynchronous constructs. However, their approach is limited to executor types within the JUC library, thus missing opportunities for broader refactoring. [PERSON] et al. [5] explored using dynamic analysis to identify opportunities to enhance program performance through refactoring traditional asynchronous constructs. They discuss replacing a pattern where asynchronous tasks submitted to an executor are merely scheduling two other asynchronous tasks with CompletableFuture's combinational capabilities to reduce scheduling overhead. However, their research focuses more on dynamic analysis and code patch generation technologies. The proposed refactoring pattern \begin{table}
\begin{tabular}{c c c c c} \hline
**Study** & **Platform** & **Supported Constructs** & **Refactored Constructs** & **Sync to Async** \\ \hline [PERSON] et al. [9] & Java & \begin{tabular}{c} Synchronized lock, \\ HashMap, \\ Sequential recursive \\ Thread, ThreadPool \\ \end{tabular} & \begin{tabular}{c} Atomic lock, \\ ConcurrentHashMap, \\ Fork/Join framework \\ \end{tabular} & Yes \\ [PERSON] et al. [6] & C\# & \begin{tabular}{c} Thead, Thread, ThreadPool \\ \end{tabular} & \begin{tabular}{c} Task \\ \end{tabular} & No \\ [PERSON] et al. [7] & C\# & \begin{tabular}{c} Callback-based asynchronous code \\ \end{tabular} & async, await & No \\ [PERSON] et al. [14] & Android & \
\begin{tabular}{c} Long-running code \\ \end{tabular} & AsyncTask & Yes \\ [PERSON] et al. [8] & Android & AsyncTask & IntentService & No \\ [PERSON] et al. [15] & JavaScript & Synchronous API functions & async, await & Yes \\ [PERSON] et al. [13] & Java & Sequential method calls & CompletableFuture & Yes \\ [PERSON] et al. [4] & Java & Future, SwingWorker & RxJava constructs & No \\ [PERSON] et al. [5] & Java & Traditional asynchronous constructs &
\begin{tabular}{c} Inline code, \\ CompletableFuture \\ \end{tabular} & No \\ \hline \end{tabular}
\end{table} 
Table 1: Comparison of Concurrency Refactoring Studies. involves transitioning from traditional asynchronous constructs to CompletableFuture, but it does not provide specific methods for the refactoring. Previous studies have primarily focused on two areas: (1) refactoring existing asynchronous constructs to more suitable alternatives [4; 5; 6; 7; 8] and (2) introducing asynchronous constructs into sequential code to improve program execution efficiency [9; 10; 11; 12; 13; 14; 15].