作者 | Karsten Silz
译者 | 张卫滨
策划 | 丁晓昀
Leyden 项目的目标是“解决 Java 启动时间慢、达到性能峰值慢和占用空间大等长期痛点问题”。它想通过在 OpenJDK 中“引入静态镜像的概念”来实现这一目标。静态镜像来自于对原生可执行文件的提前（Ahead-of-Time，AOT）编译。在两年没有公开的活动之后，Leyden 项目在 2022 年 5 月改变了方向，首先优化即时（Just-in-Time,JIT）编译。由此产生的优化几乎肯定要比最初计划的要弱，它最早会在 2025 年底交付给主流 Java 开发者。Oracle 的 Graal 项目已经实现了 Leyden 项目的目标，但其代价是该项目目前竭力想避免的。
Graal 项目起源于 Oracle Labs，并不是 OpenJDK 的一部分。它的 GraalVM Native Image 是一个 Java AOT 编译器，如今能够生成原生可执行文件。与 Java 的 JIT 编译器相比，它们有四个优势，即启动更快、内存和 CPU 占用更低、安全漏洞更少以及文件更小。
但是，这些成就是有代价的，那就是 GraalVM Native Image 对 Java 应用有一个所谓的封闭性假设（closed-world assumption）的要求，这对所有的 Java 的应用来说都是很难接受的。为什么呢？因为 Java 是一个动态语言，它在运行时赋予了应用很多的权力，比如反射、类加载，甚至构建类。有些特性在 GraalVM Native Image 的封闭世界里是无法正常运行的。这也就是 Leyden 项目现在想要“探索比封闭性假设更弱的约束，并发现它们能够实现哪些优化”的原因。尽管如此，Leyden 项目“依然有希望 [...] 生成完全静态的镜像”，只不过“这是长期来看”的目标了。
OpenJDK 以前曾经尝试过 AOT 编译
Leyden 项目是 OpenJDK 对 AOT 编译的第二次尝试。第一次尝试是 JEP 295 Ahead-of-Time Compilation 的 jaotc，并于 2017 年 9 月在 JDK 9 中交付。与 GraalVM Native Image 类似，它使用了 Graal 项目。但是，与 GraalVM Native Image 不同的是，它非常不受欢迎：当 Oracle 在 Java 16 构建版中移除 jaotc 时，“没有受到任何人的抱怨”。于是，Oracle 在 JDK 17 中，基于 JEP 410 Remove the Experimental AOT and JIT Compiler，干脆利落地移除了它。
对于 OpenJDK 项目来说，Leyden 有着不同寻常的历史。Java 语言的架构师 Mark Reinhold 在 2020 年 4 月提出了它，随后，OpenJDK 在 2020 年 6 月将其批准为一个项目。但是，从批准到 2022 年 5 月创建邮件列表的两年时间里，没有看到该项目任何明显的进展。这也就是该项目为何刚刚起步，现在主要关注的是“概念，而不是代码”的原因。Reinhold 指出，像“HotSpot JVM、C2 编译器、应用类数据共享（application class-data sharing，CDS）以及 jlink 链接工具”都是优化的目标。值得注意的是，列表里缺失的一个组件是 CRaC，它是一个 OpenJDK 项目，能够通过在磁盘中加载 Java 应用来减少启动时间。
通过反推可以得出可能的交付日期。现在，LTS 版本的重要性已经超出了预期。Ben Evans，之前就职于性能监控公司 New Relic，在 Devoxx UK 2022 上宣布“没有任何一个非 LTS 版本的市场份额超过了 1%”。这表明，主流的 Java 开发人员只会从一个 Java LTS 版本迁移至另一个 LTS 版本。
因为 Leyden 项目现在刚刚开始，估计很少有成果能够以生产可用的状态进入 2023 年 9 月份发布的 JDK 21（也就是下一个 LTS 版本）。所以，主流 Java 开发人员可能只有在 2025 年 9 月的 LTS 版本（JDK 25）中才能看到 Leyden 项目的第一批成果。基于这样的假设，Leyden 项目最早会在 2027 年 9 月通过 JDK 29 向原生可执行文件提供 AOT 编译功能。InfoQ 将继续关注 Leyden 项目的进展。
Spring Boot 对 Leyden 项目的反应
在 Leyden 考虑的特性中，至少有一些需要应用框架的支持才能发挥最佳效果，比如 jlink 或 CRaC。所以，InfoQ 联系了 Spring Boot、Quarkus 和 Micronaut 的开发者，了解他们对 Leyden 公告的初步反应。
Spring Framework 的项目负责人 Juergen Hoeller 对 Leyden 项目表示了认可：
Leyden 项目是一个很有前途的倡议，与我们在 Spring Framework 6 和 Spring Boot 3 的大方向上是一致的。
Hoeller 还欣然接受在 Spring 中支持 CRaC：
CRaC 堆快照可以作为改善 Spring 应用的启动时间的通用方案。在应用启动的最后阶段生成快照，此时几乎没有任何处于打开状态的文件或网络资源，这符合 CRaC 的预期。Spring 甚至已经在应用上下文刷新结束时重置了它的通用缓存，在用请求相关的元数据动态地重新填充缓存之前清除了启动相关的元数据。在 [......] 应用上下文对快照事件的具体反应，以及改进通用组件的“快照安全”方面，我们肯定会在技术上可行的情况下，在 Spring Framework 6.x 产品线中努力为早期采用者赋予更多的能力。
Hoeller 认为 Spring 将会很快支持 jlink 和 Java 平台模块系统（Java Platform Module System ，JPMS）：
目前的 Spring Framework 6.0 的里程碑版本还不包括 module-info 描述符。但这在 9 月份 M6 里程碑版本的路线图上，在我们进入 6.0 的发布候选阶段时，会重新评估第三方生态系统的模块系统就绪情况。由于 Leyden 项目有可能将 jlink 变成一个更强大、更通用的工具，所以我们计划不仅为 jlink 目前的能力做好准备，也会考虑它进一步的演进。
Quarkus 对 Leyden 项目的反应
Quarkus 的联合创始人和共同负责人 Jason Greene 对 Leyden 项目发表了评论：
我们对 Leyden 项目修改 Java 语言规范以更好地支持静态镜像、原生编译和其他技术（如 JVM 检查点）的目标感到最为兴奋。此外，我们很高兴看到封闭性假设仍然可能是该项目的长期目标。
Greene 也欣然接受在 Quarkus 中支持 CRaC：
最近，对 CRaC 研究项目的初步支持已经由 CRaC 的负责人贡献给了 Quarkus 项目。不管运行时的目标类型是什么，Quarkus 都会进行构建时的优化，所以在 OpenJDK 上运行时，我们依然能够看到相当可观的成本节省，而不仅限于 GraalVM。在 OpenJDK 之上添加检查点的方式，比如 CRaC，能够进一步优化启动时间。它无法带来类似于原生镜像那样的成本节省，但是对倾向于或必须采用 JVM 执行的应用来讲，未来这都是一个很有意思的可选方案。
但是，Greene 对于在 Quarkus 中使用 jlink 和 JPMS 并没有表现出太高的热情：
截止到目前为止，jlink 只是为基于 JVM 的应用的存储开销带来了好处（不管有没有它，内存开销和启动时间基本上都是一样的）。但是，在容器和 Kubernetes 应用中，常见的实践是在标准 JVM 基础镜像上建立新的层，这已经比将所有的应用切换到 jlink 上带来了更多的成本节省（因为每个人都会打包自己裁剪过的 JVM）。在原生镜像的场景中，JVM 的细粒度元素编译到了镜像中，所以在这种情况下，jlink 也提供不了什么帮助。
同样，对于 JPMS，Quarkus 已经通过 Quarkus 扩展实现了自己的模块化理念，允许我们将依赖集修剪到只包含所需的内容。Quarkus 所采取的方式与简单扁平化 classpath 是兼容的，这也是大多数 Java 生态系统和构建工具如今所偏爱的方式。在成本方面，如果按照 jlink 的要求转向纯 JPMS 模块（没有自动模块），那么将意味着不仅对 Quarkus，还对 Quarkus 构建所需的大量的库都会产生破坏性的变更。在考虑进行转换之前，我们希望看到这些因素能够更好地平衡。
Micronaut 对 Leyden 项目的反应
Object Computing, Inc.（OCI）的首席软件工程师 Sergio del Amo Caballero 对 Leyden 项目没有发表 Micronaut 框架的官方声明。但他在最近一个关于在 Micronaut 上添加对 CRaC 支持的 GitHub issue 上对此进行了阐述。
Caballero 还分享了 2020 年 7 月的一段 YouTube 视频，视频中 Micronaut 的创始人 Graeme Rocher 对 JPMS 进行了评论：Micronaut 支持 JPMS 并发布了 module-info 文件，但必须要“在支持 Java 8 之间取得平衡”。JPMS 是在 Java 9 中加入的，但 Micronaut 3.5，即当前版本，仍然运行在 Java 8 上。
结 论
到目前为止，OpenJDK 还没有解决“Java 启动时间慢、达到性能峰值慢以及占用空间大的问题”。首先，它的 jaotc AOT 编译器并没有得到足够的动力，并且已经废弃了。随后，Leyden 项目开始对 Java 的原生编译进行标准化，但停滞了两年之久。
现在，Leyen 项目已经转向首先优化 JIT 编译，情况正在好转：Spring 和 Quarkus 都拥抱 CRaC 以减少启动时间。但是当涉及到实现较小的 Java 应用时，只有 Micronaut 坚持 Leyden 项目的建议，即使用 JPMS。Spring 计划在 2022 年底的 6.0 版本中支持 JPMS，不过 Spring 生态系统可能还不会这样做。而 Quarkus 目前没有计划加入 JPMS。
Leyden 项目的成果，最早可以在 2025 年底以 JEP 的形式到达主流 Java 开发者手中。因此，至少在那之前，将 GraalVM Native Image AOT 编译器与 Quarkus、Micronaut 或即将推出的 Spring Boot 3 等框架结合起来，仍然是避免“Java 启动时间慢、达到性能峰值慢以及占用空间大的问题”的最佳选择。
作者简介：
Karsten Silz 全栈 Java 开发人员，Karsten Silz 在欧洲和美国工作了 23 年。2004 年，他在美国合伙创立了一家提供软件产品的初创公司。Karsten 领导了 13 年的产品开发，并在公司成功出售后离开。自 2017 年以来，他一直在德国和英国做承包商（Spring Boot、Angular、Flutter）。2020 年，他作为 CTO 共同创立了 SaaS 初创公司“Your Home in Good Hands”。
原文链接：
https://www.infoq.com/news/2022/06/project-leyden-delays-aot/
点击底部阅读原文访问 InfoQ 官网，获取更多精彩内容！
今日好文推荐
微软开始封禁商业开源：从 App Store 入手，7 月 16 日生效？！
迁移进行时，告别 GitHub 的时候到了？
腾讯安全回应数据产品线裁撤；马斯克称终止收购推特；拼多多“砍一刀”涉嫌欺诈案一审宣判 ｜Q 资讯
GitLab 技术选型为何如此不同：坚持用过气 Web 框架十多年、坚决不用微服务
