# Automatic Refactoring Approach for Asynchronous Mechanisms with CompletableFuture
## 1 Introduction  
Java has supported asynchronous programming since its earliest versions, with continuous enhancements to its asynchronous capabilities as technology has evolved. A significant advancement came with the introduction of the java.util.concurrent (JUC) library in Java 5, which markedly improved asynchronous programming. A key enhancement in this library is the ExecutorService framework. This framework decouples the lifecycle management of threads from task execution and avoids the performance overhead associated with the frequent creation and destruction of threads by reusing them. It allows asynchronous tasks that implement the Callable or Runnable interfaces to be submitted for execution to an executor while returning a Future object as a handle for the asynchronous task. Through this handle, developers can access the task's execution status and results. We refer to this mode of asynchronous programming as the \"traditional asynchronous construct\". It has been well-received and widely used by developers, ranking as the second most popular asynchronous programming pattern after Thread, according to our empirical research results presented in Section 4. As time has progressed, some challenges associated with using traditional asynchronous constructs in real-world applications have sparked extensive discussions in developer forums [1, 2], particularly the lack of phased control in the ordinary Future returned by traditional constructs, which makes orchestrating asynchronous tasks exceptionally difficult. The introduction of the CompletableFuture class in Java 8's JUC addresses these issues. CompletableFuture implements the Future interface and extends the CompletionStageinterface. This extension provides callback mechanisms and chainable method invocations to compose and orchestrate asynchronous computations. Additionally, it integrates functional programming interfaces and lambda expressions, enhancing the readability of asynchronous code. It also introduces an exception-handling mechanism, simplifying exception management during asynchronous task execution. However, according to the empirical research results presented in Section 4 of this paper, only 3.53% of popular Java open-source projects on GitHub have adopted CompletableFuture. On one hand, this is related to the relatively late introduction of CompletableFuture. Traditional asynchronous constructs had already become deeply ingrained, and the existence of similar alternatives to CompletableFuture in popular asynchronous libraries within the Java community, such as ListenableFuture in Google's Java core library Guava [3], has affected the popularity of CompletableFuture. On the other hand, due to CompletableFuture's rich API, which results in a higher learning curve for programmers, many have missed the opportunity to utilize it. Although refactoring traditional asynchronous constructs to CompletableFuture constructs can provide software developers with more powerful and flexible asynchronous programming capabilities, as discussed in developer forums [2], this transition is not without barriers. Firstly, there needs to be a method to assess whether the logic for submitting asynchronous tasks via executors is compatible with CompletableFuture. Various executor types in the JUC library meet refactoring criteria, but developers often use custom ExecutorService interfaces. This requires analyzing non-JUC executor types in projects to identify which are refactorable. Secondly, because CompletableFuture uses Supplier-type asynchronous tasks with return values, it is necessary to refactor Callable-type asynchronous tasks into Supplier-type. Furthermore, the cancellation mechanism of CompletableFuture differs from that of FutureTask, the Future object type used traditionally. This difference can cause issues if tasks depend on FutureTask's cancellation feature. Lastly, refactoring changes the actual type of Future objects; if the code includes type comparisons or type conversions of Future objects, refactoring should be avoided.