# Migrating from Developing Asynchronous Multi-Threading Programs to Reactive Programs in Java
## 8 Conclusions and Further Development  
### Conclusions  
Based on the analyses and test results, an iterative refinement process is essential to enhance performance and address identified limitations. This approach, akin to the iterative refinement described in software development methodologies [72], may involve further adjustments to the algorithms and the reactive architecture, ensuring that the system effectively meets scalability and stability requirements.  
As part of the project, two complete backends were developed based on the asynchronous and reactive models. Both applications were extensively tested by defining and executing equivalent unit tests and identical automated integration tests, indicating functional equivalence between the two models, with all the considered scenarios demonstrating similar behavior and reinforcing the viability of transitioning towards the reactive paradigm without compromising the existing functionality.  
From a performance point of view, the reactive variant achieved significantly better response times but also proved to be more efficient by using a reduced number of threads and resources in most of the evaluated scenarios due to the non-blocking, event-driven architecture. However, in some complex scenarios, it still presented limitations and was outperformed by the asynchronous model, highlighting that its effectiveness might fluctuate depending on the nature of the tasks.  
The reactive approach consistently outperformed its asynchronous counterpart in memory efficiency, avoiding aggressive thread pool expansion and significant memory spikes under increased concurrency. When assessing CPU efficiency, the reactive approach demanded more resources in scenarios that involved intensive data processing, suggesting a potential trade-off where higher CPU consumption compensates for greater performance stability. Despite the higher demands in some contexts, it delivered sustained performance across varying operational scenarios, showcasing adaptability in resource management.  
In evaluating performance indicators such as average response times, throughput, and 90 th percentile response times, the reactive model generally demonstrated greater efficiency across the examined scenarios. However, not all tests consistently favored the reactive model, with some scenarios showing comparable average response times between the two models. The reactive model's superior throughput and stability, highlighted by the 90 th percentile response times, demonstrates its ability to handle requests quickly and consistently under load. This reliability, particularly in high-demand environments, confirms the reactive model as a suitable choice for scenarios requiring robust and efficient handling of large request volumes, despite occasional setbacks in specific demanding tasks.  
It must be emphasized that limitations and challenges in migrating to the reactive paradigm remain significant. The migration process to a reactive model can be a viable option, whether applying a partial migration to only critical components or transitioning towards fully reactive systems is considered. Analyzing the specifics of each product and making an informed decision remain the determining factors. This project offers a starting  
Figure 9: Testing environment diagram.  
point for such investigations and decisions, to promote a better understanding of both the advantages and challenges associated with reactive programming in the Java ecosystem.