Your link is about a completely separate feature, called the AOT code cache (targeted for JDK28, not released yet). The post is about the AOT cache, which forms the foundation for this feature, but is separate and already available since JDK24. The JEP for the feature the post is about is https://openjdk.org/jeps/483

I wonder if this should trigger a warning (or even an error) at application startup whenever the CPU architectures differ.

IMHO, that would be much better than running into crashes and having to figure out the cause yourself.

Yeah, there are some strange expectations going into this.

"This is what I would like AOT cache to mean."

Yes. And this is the right tradeoff vs the ossification you saw previously in Java (and we're starting to see now in Python, see the recent ejection of the CPython JIT), especially now when you can say "GPT, source dive the JDK and figure out which cutting edge is causing the bleeding."

I spent a couple weeks trying to bolt this on to our setup to support a more serverless style approach. OpenJ9 (sadly) really didn't work out well, perhaps we run in a way they don't optimize for. Azul and OpenJDK's approaches helped - but it is quite intrusive (you need a profiling run), and the absolute benefits aren't that great. It's mostly doing classpath stuff at present, and not really AOT work on machine code (though that is in the pipeline).

All in all, I wasn't particularly impressed with the outcome. Obviously GraalVM has more headroom, but that's an even more intrusive change.

When compared with a Rust port of our service, the delta of the efforts is absolutely astronomical. Ridiculous performance, near-instant startup, radically less memory consumption. I mean - duh - but nonetheless, when I contrast the effort vs payback, it's very hard for me to want to invest so much in techniques that have so little payback (graal) when I can put that into an approach that leaves me in a much better place long-term.

If I had mountains of legacy, obviously I couldn't do that, but in my situation it seems like a much more attractive option.

It's normally an opt-in thing I think, since it's not an unconditional win: you have to figure out which code paths are worth it, and then where to trade off binary bloat vs the runtime cost of dynamic dispatch. In rust for example:

https://doc.rust-lang.org/beta/core/arch/#dynamic-cpu-featur...

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.

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?

Yes (or something along those lines), it's just that this isn't the first use case addressed by this capability, which is being delivered gradually (as we normally do in the JDK), and not even all the basic building blocks are out yet.

That, and I think the cache busting based on CPU/environment probing logic will need to be significantly improved. Any difference in CPU features should not bust the cache; specific differences should bust the cache.

There also might be a need for "downgrading" cross-compilation profiles a la "don't compile/AOT-cache this app for the current CPU, compile/cache it for <the kind of CPU that I have 10k EC2 instances running>". You'd think that would be easier to achieve by just compiling on a production-like machine, and you'd be disappointed by the number of shops running Java apps hand-built on a Windows laptop across millions of cloud Linux cores.

If you are regering to the mess that is python or javascript in beg to differ