What are the most common ways to improve warmup times, actually? Looked a bunch into this, primarily native image, aot and crac, all of them super messy to get to work with a normal JVM webapp. I understand the warmup concept is inherent in JIT compilation, but how are big companies like Netflix handling this to quickly scale microservices horizontally etc?

Native images shouldn't be too messy anymore, Oracle put a lot of effort into DX improvements and all major web frameworks are now aware it's an important and growing use case.

Struggling to build native images should be a sign you're reliant on libraries that are dangerously outdated and abandoned.

They can definitely be pretty messy in some ways; even the standard library doesn't work out of the box perfectly. I have certainly struggled to get image manipulation with java.awt (e.g. thumbnail generation for a fairly standard web use case) to work in a native image.

So it is an antipattern nowadays to manipulate the classpath after building? Iirc native image require static classpath, but it is quite common to inject e.g. environment specific data via the classpath. Should one just read from the filesystem instead, or what’s the strat there?

With the AOT cache, you can actually modify the classpath (or module path as is now used for modern applications) after it has started up. The names and classes for the APIs are different, but you can still load jars at runtime even with the AOT cache enabled and functional.

The AOT cache compatibility issues come when your boot module path differs between training and actual run. As long as that is not the case, you can use it without problem and load additional modules at runtime after it has started up.

With GraalVM, that is not possible. It still has the closed-world assumption.

I mean, how fast do you need it to be? If you're running lambdas with cold starts all day long yes, java is a problem. Otherwise, occasional restarts of java services are quick assuming they're probably stateless. A few seconds? Whats the problem that needs to be solved here?

I’ve experienced deployments under heavy load being quite painful with slow restarts, even when doing e.g. canary releases. Blue/green would work but was in an environment where we couldn’t deploy immutably, we had to mutate the existing deployment in place.

I actually agree but what even is ”production grade”? More complexity and excessive fault handling? Nah, happy path coding ftw. Production grade software = collective understanding of the system imo

"Production-grade" typically means something that has been battle tested by users and has gone through all the trials and tribulations of dealing with their complains, suggestions, and other feedback to see an initial vision (the prototype) become what users actually want and need.

The earlier quote might be slightly overblown as some of those complaints, suggestions, and feedback can be iterated on more quickly thanks to AI. However, I think you will find that the overall premise is sound: The feedback loop is where you will spend the vast majority of your time and no coding agent can speed that up. Code was never the real bottleneck. A full-day coding session now being a 15 minute coding session helps, every so slightly, but when you still need to spend weeks talking to the users to figure out what needs to be done in that day/15 minutes, shaving off a handful of hours relative to weeks remains but a drop in the bucket. The marginal improvement is barely worth recognizing.