Hi, I would like to emphasize as well that build time initialization is not just about native image. AOT is clearly an important target but there are significant benefits to Java, Hotspot and regular JIT based applications in being able to precompute framework infrastructure. The fact that frameworks like Micronaut and Quarkus compute this infrastructure at build time results in massive improvements to startup time and memory consumption, that are not achievable with a runtime scanning approach in particular as an application grows in size.
Which is funny in a way, as that was how early versions of EJB worked ;) Then at some point we decided we all disliked this, and switched to the runtime scanning approach. Seems Andy Tanenbaum is once again right ;)
Well to be fair, I don’t think it was a bad decision at the time. Things have changed though. Historically the life-cycle of the application server / runtime / JVM was much longer than an app, since it *was* your infrastructure. Under that model, it's desirable to have an ultra-dynamic system that can react and pick up changes (potentially even incremental changes). Under the cloud era, kubernetes plays the role of “app server” and the runtime and the app now have a life-cycle that is one and the same. Further they are deployed together in an immutable container. So in that environment, runtime scanning and dynamic initialization are just costs that delay an answer which will always be the same. Further, you tend to repeat them more because of elastic horizontal scaling up and down vs in the past you just had a long running dedicated bare metal system.
-Jason |
