This is fine. However one thing that is not clear to me is why after telling for decades that startup time and memory usage does not matter, Java world is promoting Graal native so much.
As someone who's spent much of the last 20 years writing J2EE, Java EE and Jakarta EE projects, the answer is definitely that with containers and container orchestration, no one believes it anymore. Our new services are written in Go and have significantly shorter start-up times and smaller memory usage and it does matter (to us at least)!
I think this touches on some of the points that GraalVM/Mandrel and Quarkus are trying to address. No one wants those large J2EE/Spring monoliths anymore especially if they're deploying to K8s. Being able to quickly spin up replicas is where that short startup time and smaller memory usage comes into play. Scaling out vs scaling up (horizontal vs. vertical) is what Java devs have needed and it's being addressed with these new technologies.
Agreed ... but as noted elsewhere in this thread, your chance of getting a Wildfly (e.g.) application running in Quarkus and compiled to native via GraalVM is pretty small unless you've got a pretty standard CRUD application. We run into all sorts of problems with connections to anything that isn't a database including jobs that process JMS messages in an async fashion.
The goal is to remain competitive with Go. Java is still going to excel in cases when the benefits of JIT and superior GC have the opportunity to show themselves.
Graal native gives up the benefits of JIT for fast startup. It might be a useful tradeoff for some but it is not a universal solution.
The funny thing is HotSpots startup time and memory usage are drastically lower on jdk 14 vs 8 [0].
I think the next step for Java will be more people shifting to using ZGC which automatically releases unused heap back to the OS where the current default (G1) doesn't.
