https://foojay.io/today/how-is-leyden-improving-java-perform...
I long ago concluded that Java was not a client or systems programming language because of the implementation priorities of the JVM maintainers. Note that I say priorities--they are extremely bright and capable engineers that focus on different use cases, and there isn't much money to be made from a client ecosystem.
AOT options like GraalVM Native Image can help cold starts a lot, but then half your favorite frameworks breaks and you trade one set of hoops for another. Pick which pain you want.
There are JITs that use dynamic profile guided optimization which can adjust the emitted binary at runtime to adapt to the real world workload. You do not need to have a profile ahead of time like with ordinary PGO. Java doesn't have this yet (afaik), but .NET does and it's a huge deal for things like large scale web applications.
https://devblogs.microsoft.com/dotnet/bing-on-dotnet-8-the-i...
The folks on embedded get to play with PTC and Aicas.
Android, even if not proper Java, has dex2oat.
if it is valuable, i'd be surprised you can't freeze/resume the state and use it for instantaneous workload optimized startup.
Too many folks have this mindset there is only one JVM, when that has never been the case since the 2000's, after Java for various reasons started poping everywhere.
in practice, for web applications exposing some sort of `WarmupTask` abstraction in your service chassis that devs can implement will get you quite far. just delay serving traffic on new deployments until all tasks complete. that way users will never hit a cold node
There are options to turn on which cause the JVM to save off and reload compiled classes. It pretty massively improves performance.
You can get even faster if you do that plus doing a jlink jvm. But that's more of a pain. The AOT cache is a lot simpler to do.
Because in my experience as of 2026, Java programs are consistently among the most painful or unpleasant to interact with.
> But people just want to compare it to building a cli tool in go or rust.
This seems like the key. HN is definitely biased towards simpler, smaller tools. (And that's not a bad thing!). The most compelling JVM stories I hear are all from much larger scale enterprise settings.
Kafka being a good example. It's very good at what it does, but painful to manage and usually not worth the pain for anyone who's not in a mega enterprise.