行业动态
openjdk.org ·
@Hacker News
JEP 544：Java 提前编译（AOT）提案
OpenJDK 提出 JEP 544，主题为 Java 的提前编译（Ahead-of-Time Code Compilation）。该提案明确‘不支持 HotSpot 当前支持的全部 CPU 架构’并非目标，但表示预期通过常规移植工作最终覆盖主要架构。Hacker News 讨论中将其与 GraalVM Native Image、Project Crema、Excelsior JET 和 IBM J9 的既有 AOT 方案进行比较，并讨论 JVM 作为沙箱与跨平台抽象层的定位变化。输入未包含 JEP 正文，具体实现细节与落地时间尚不明确。
AI推荐理由 OpenJDK 官方 JEP 544 提案页面，主题为 Java 提前编译（AOT），来源权威、事实明确，属开发者工具链层面的实质进展。输入仅含 HN 讨论区评论片段（10 分、8 条评论），未提供 JEP 正文细节，无法评估具体实现范围与时间表；评论中关于 GraalVM Native Image、Project Crema、Excelsior JET、IBM J9 的对比属个人观点，不能作为已验证结论。对 JVM 生态与编译优化方向有参考价值。
68
正文
Domain: openjdk.org
Points: 10 | Comments: 8
[Top Comments]
- I hope at some point we'll get AOT-only mode (or compile to native) and maybe even cross-compilation.
- We have that in Codename One, yes it's not really "Java" but it compiles bytecode AOT and cross compiles to some of the platforms.
- If you haven't checked it out yet, GraalVM's Native Image [1] already let's do AOT compilation suitable for distribution. You have to do some configuration to deal with reflection and dynamic class loading since there's no JVM in the produced build, but it comes with tooling to simplify that. And that restriction is being addressed by Project Crema [2].
[1] -- [https://www.graalvm.org/latest/reference-manual/native-image...](https://www.graalvm.org/latest/reference-manual/native-image/)
[2] --
- progress, not perfection! Java is on fire right now with new stuff landing. We'll get there!
- Excelsior JET did that 25 years ago:
It's a shame that Sun/Oracle never partnered with them to bring native apps. This could have saved Java on the desktop.
- IBM's J9 had AOT for a long time too. I wonder how JEP 544 compares.
- So we've gone full circle again?
I suppose write once run anywhere is no longer a goal either.
"It is not a goal to support all CPU architectures currently supported by HotSpot."
This pretty much validates the point of view that VM design is now baggage, as a sandbox it has been flawed, for performance it's been prohibitive, and cross platform portability by virtue of being virtual, was just a convenient byproduct.
AI now handles the portability, sandbox security hasn't changed (cf. docker still has sandbox problems, LLMs have sandbox problems, it's always an ongoing concern) and that just leaves Java, as always, chasing performance.
- The very next sentence after the one you posted is "We expect normal porting activities to eventually add support for all major architectures." Goals and non-goals inform the scope of the proposal. Given this is effectively an "add-on", I don't think it's unreasonable to prioritize the most popular platforms. Others will continue to execute Java perfectly fine in JVM mode.