You’ve probably noticed the shift. The magic trick that defined your career—write once, run anywhere—is quietly being walked out to the woodchipper. For decades, we treated the JVM as the ultimate superpower. Now, in the era of serverless and microservices, it’s just dead weight.
The JVM didn’t become a liability because it got worse. It became a liability because the world we built it for no longer exists.
Look at JEP 544 and Project Leyden. The Java ecosystem is aggressively pushing Ahead-of-Time (AOT) compilation. Why? Because in the cloud, cold starts are murder. One developer recently noted that a trivial Java program takes 2.5 to 3 seconds just to spin up. Go does it in 1.7 seconds. Swift does it in milliseconds. When you’re paying by the compute millisecond, a 3-second JVM startup isn’t a feature. It’s a tax.
We used to mock Excelsior JET for trying to compile Java to native code 25 years ago. We said it missed the point of the virtual machine. Today, JEP 544 is practically admitting the old point is dead. The spec literally states, “It is not a goal to support all CPU architectures currently supported by HotSpot.”
Write once, run anywhere is dead. We traded universal portability for millisecond startup times, and we didn’t even hesitate.
Most engineers frame AOT as a technical optimization. It’s not. It’s a philosophical surrender. We are abandoning the core ideal of Java to stay relevant against Go and Rust. We are becoming the very native-compiled languages we once abstracted away.
But this transition is brutal. AOT requires “training runs” to collect profiling data, and as one developer pointed out, the tooling for this is a massive burden. You end up building bespoke pipelines just to make your Java app behave like a Go binary. The sandbox we loved is being dismantled piece by piece.
We spent thirty years building the perfect sandbox, only to realize the cloud wants a sniper rifle, not a Swiss Army knife.
The nostalgia is real. It’s frustrating to watch the VM abstraction get framed as legacy overhead by devs who never had to manually manage memory. But holding onto the past is a death sentence. The future of Java is native, it is platform-specific, and it requires us to let go of the very thing that made us fall in love with it in the first place.
FAQ
Q: Isn't AOT just an optional optimization for edge cases?
A: No. In a serverless world, a 3-second startup time is a fatal flaw. AOT is becoming the default because the cloud charges you for cold starts, and the JVM's dynamic optimization can't save you there.
Q: Do I need to rewrite my Java apps now?
A: Not immediately, but you need to rethink your build pipelines. You'll be setting up training runs and native packaging, trading your zero-config portability for sheer execution speed.
Q: Was the JVM never actually a superpower, just a patch for slow hardware?
A: Exactly. We worshipped an abstraction that compensated for 90s hardware limits. Now that hardware is infinitely faster and distributed, the abstraction is just dead weight.