# A Comparative Assessment of JVM Frameworks to Develop Microservices
## 5 Discussion  
In this study, the objective was to evaluate comparatively and critically the most promising JVM frameworks supporting the development of microservices. To this end, synthetic benchmarks were developed to reflect the most common uses of web services. Then performance tests of various workloads were carried out in a controlled execution environment using these benchmarks. The empirical results obtained allowed us to make some interesting observations. Obtained results and insights learned can be analyzed and presented in many ways. A decision has been made to show the results in two contexts--a general one that will focus on the main differences noticed between analyzed frameworks and in the context of the comparison between the usage of the traditional JAR executable files approach and the emerging new technique of the native image files still considering studied frameworks as well. Starting from the factors that were noticed during the application preparation phase, we can see that Spring Boot leads the way in terms of documentation. The much younger competitors, for now, cannot stay ahead of their older rival regarding the accuracy, exten  
Figure 12: CreateFetchPatchDelete test results. sivity and the number of examples available in the documentation (but on the Internet itself as well). Analyzing the compilation time under test (Figure 3), we can see the different approaches taken in the Micronaut and Quarkus directly impacting the results and translating into the application start time. Spring Boot relies on the reflection and proxies in its IoC container implementation and uses it in the dependency injection process. Based on the Spring framework experience and awareness of the burden the usage of runtime-based techniques combined with reflection and proxies carries, the others tend to minimize their use in their IoC/DI solutions and leverage ahead-of-time compilation as much as possible. It is worth noting that Spring also starts to go towards that direction with the announced initial AOT support and optimization at the build time forthcoming with Spring 6.0. Independently from the executable format, we can see the benefits of that approach which, however, comes at a price. The compilation time for JAR files is noticeably longer for the Micronaut and Quarkus as they shift most of the operations that (in the case of Spring Boot) are done in runtime to the compilation time. Nevertheless, this gives the significant benefit of a shorter startup time (Figure 4a) that can be crucial from the point of view of autoscaling. We can see a bit of a different effect for the compilation time in the native image (Figure 3b). Higher reliance on the reflection causes an increase in it, as it must be registered upfront and probably requires additional operations during compilation. Yet, as in the case of the JARs, the achieved startup times by Spring Boot are worse than the competition (Quarkus and Micronaut) (Figure 4b). Moreover, regarding the compilation time for the native image, we can see that both Quarkus and Micronaut achieved almost the same and the best result. When considering the JAR executable, Micronaut is the leader. The usage of the custom fast-jar approach in the Quarkus, which for some time has been the default approach in the framework, still is a bit behind the fastest competitor. As part of the observations made, it is worth noticing that Micronaut, by default, uses lazy initialization. It results in a much longer time to handle the first request (around 1-3 s) as the underlying components, such as services, etc., are only created. Possibly, these could impact the visible dominance of the Micronaut in terms of the startup time for the JAR executable. Moving on to the topic of the executable file and the image size (Figure 5), regarding the JAR executable, we can see that Micronaut is the leader, with the result lower by over 10 MB from the most extensive Quarkus JAR file.