[kyrra]

First request latency also can really suck in Java before hotpathed code gets through the C2 compiler. You can warm up hotpaths by running that code during startup, but it's really annoying having to do that. Using C++, Go, or Rust gets you around that problem without having to jump through the hoops of code path warmup.

I wish Java had a proper compiler.

[pron]

You mostly need a recent JDK. Leyden has already cut down warmup by a lot and is expected to continue driving it down.

https://foojay.io/today/how-is-leyden-improving-java-perform...

https://quarkus.io/blog/leyden-1/

[looperhacks]

You can create a native executable with GraalVM. Alternatively, if you want to keep the JVM: With the ongoing project Leyden, you can already "pre-train" some parts of the JVM warm-up, with full AoT code compilation coming some time in the future.

[Thaxll]

GraalVM has a lot of limitations, some popular lib don't work with it. From what I remember anything using reflection is painful to use.

[senkora]

And going the other direction, if you want your C++ binaries to benefit from statistics about how to optimize the steady-state behavior of a long-running process, the analogous technique is profile-guided optimization (PGO).

[vbezhenar]

GraalVM is terrible. Eats gigabytes of memory to compile super simple application. Spends minutes doing that. If you need compiled native app, just use Golang.

[brabel]

I used to be really excited about GraalVM but this, together with limitations in what Java code can run (reflection must be whitelisted - i.e. pain) made me run away from it. I do use Go, but my favourite substitute for Java is actually Dart. It can run as a script, compile to a binary or to a multiplatform "fast" format (a bit like a jar), and performance wise it's par on par with Java! It's faster on some things, a bit slower on other... but in general, compiling to exe makes it extremely fast to start, like Go. I think it even shares some Go binary creation tooling since both are made by Google and I remember when they were implementing the native compiler, they mentioned something about that.

[gf000]

But you only need to do that before a release. You can just develop with the normal JVM with ultra fast incremental builds and hot reload.

[titzer]

I worked on JVMs long ago (almost twenty years now). At that time most Java usage was for long-running servers. The runtime team staunchly refused to implement AOT caching for as long as possible. This was a huge missed opportunity for Java, as client startup time has always, always, always sucked. Only in the past 3-5 years does it seem like things have started to shift, in part due to the push for Graal native image.

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.

[bob1029]

AOT is nice for startup time, but there are tradeoffs in the other direction for long tail performance issues in production.

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...

[asternout]

Java definitely does have that, although maybe not in the most commonly used JDK distributions. E.g. companies needing ultra-low latency even before the first request, would use Azul JDKs like Prime (paid), pre-train the profile in non-production environments, and then use it in production on new version deployment.

[pjmlp]

Excelsior JET, now gone, but only because GraalVM and OpenJ9 exist now.

The folks on embedded get to play with PTC and Aicas.

Android, even if not proper Java, has dex2oat.

[ksec]

There used to be GCJ as well. But that was at least 15 years ago.

[taeric]

I challenge the idea that first request latency is bottle necked by language choice. I can see how that is plausible, mind. Is it a concern for the vast majority of developers?

[dionian]

This is why I use java for long running processes, if i care about a small binary that launches fast, i just use something slower at runtime but faster at startup like python.

[packetlost]

Python startup time can be pretty abysmal too if you have a lot of imports.

[ptx]

This is addressed by PEP 810 (explicit lazy imports) in Python 3.15 (currently in alpha): https://peps.python.org/pep-0810/

[packetlost]

Yeah, but it requires code changes to matter

[cogman10]

So long as you aren't in a docker container, The openjdk can do fast startup pretty trivially.

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.

https://openjdk.org/jeps/514

[AlotOfReading]

And then you get applications choosing the worst of both worlds, like bazel/blaze.

[a-dub]

i'd be curious about a head to head comparison of how much the c2 actually buys over a static aot compilation with something serious like llvm.

if it is valuable, i'd be surprised you can't freeze/resume the state and use it for instantaneous workload optimized startup.

[gf000]

> can't freeze/resume the state

I mean, both of your points are a thing, see https://www.azul.com/products/components/falcon-jit-compiler... for LLVM as a JIT compiler

and https://openjdk.org/jeps/483 (and in general, project Leyden)

[bombcar]

Do none of the JVMs do that? GraalVM?

[pjmlp]

They do, to add to another comment of mine elsewhere, JIT caches go all the way back to products like JRockit, and IBM JVM has and it for years in Maestro, now available as OpenJ9.

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.

[user3939382]

My architecture builds a command registry in Clojure/JVM which runs as a daemon, the registry is shared by a dynamically generated babashka (GraalVM) shell that only includes whitelisted commands for that user. So for the user, unauthorized commands don’t even exist, and I get my JVM app with no startup overhead.

[rileymichael]

the best way is via CRaC (https://docs.azul.com/crac/) but only a few vendors support it and there’s a bit of process to get it setup.

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

[zelphirkalt]

But then we can complain about the long start time for each instance or JVM. It is choosing a different trade-off.

[rileymichael]

start time generally isn't a huge concern for web applications (outside of serverless) since you've got the existing deployment serving traffic until its ready. if you're utilizing kubernetes, the time to create the new pods, do your typical blue-green promotion w/analysis tests etc. is already a decent chunk of time regardless of the underlying application. if you get through it in 90 seconds instead of 60, does that really matter?

[belfthrow]

I really hate how completely clueless people on hn are about java. This is not, and has not been an issue for many many years in Java and even the most junior of developers know how to avoid it. But oh no, go and rust is alwaayssss the solution sure.

[pythonaut_16]

Can you provide any examples or evidence of Java apps that prove this?

Because in my experience as of 2026, Java programs are consistently among the most painful or unpleasant to interact with.

[dionian]

IntelliJ IDEA is reasonably fast, but of course its hard to make a big desktop app in java be fast.

[belfthrow]

Crac / aot cache / ready now all can address this. Not even considering native aot. Multiple low latency trading systems across market markers, hedge funds and ibs prove this. But people just want to compare it to building a cli tool in go or rust.

[pythonaut_16]

But like can you provide an actual example of an application?

> 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.

[belfthrow]

Because in real life, real world applications software is large, long running and needs to be bulletproof. Clis are not powering the world's infrastructure via piped bash scripts. It really baffles me what people actually do as software engineers on here with some of the nonsense that gets thrown around.

[bombcar]

Ah, but let's port rust to the JVM!