Asymm Systems 发布了 Eliya 25.0.3。这是一个基于 OpenJDK 25 LTS 的发行版，引入了 JVM 级策略入口，可通过可选参数 -XX:EliyaProfile=Production 启用生产环境诊断配置。Eliya 于 2026 年 6 月正式发布，面向需要在生产环境中收集崩溃、内存和运行时可靠诊断能力的 Java 团队，尤其适用于需要将诊断数据用于审计或事故分析的受监管行业。Asymm Systems 强调，Eliya 是一个偏保守的 OpenJDK 发行版，而不是新的 Java 框架、语言扩展或应用 API。
目前提供的生产配置将多项已有的 HotSpot 功能整合到一个统一的配置入口中。启用后，系统会在发生内存溢出（OOM）时，将堆转储（Heap Dump）保存到按服务划分的固定目录；开启 OOM 后自动退出，便于容器编排系统自动重启；将本地存储跟踪（NMT）设置为总结模式；统一 hs_err 崩溃日志的输出位置；并启用进行 JFR 采样和性能分析器（Profiler）挂载所需的诊断 VM 选项。此外，该配置也保留了 JDK 25 默认启用的容器支持，以保证后续版本的兼容性。
在 Foojay 发布的一篇介绍 Eliya 的文章中，Asymm Systems 首席架构师 Fahim Farook 表示，第一阶段并没有引入任何现有 JVM 参数无法实现的新运行时行为。本次发布中，EliyaProfile 的主要价值在于为 JVM 建立一个统一的策略入口，为未来可能需要修改虚拟机实现的新能力预留扩展空间。
Eliya 的设计理念认为，大多数生产环境策略都不应该放在 JVM 内部。服务认证、网络控制、任务调度、密钥注入、资源限制、堆大小配置以及垃圾回收策略等，更适合由 Kubernetes、服务网格、准入控制器、启动脚本或平台默认配置负责管理。
项目认为，只有满足以下两种情况时，策略才适合放入 JVM 层。一种是 Reach（可达性），即相关行为没有可供外部系统控制的接口；另一种是 Non-overridability（不可覆盖性），即虽然外部能够配置该行为，但运行过程中仍可能被修改或绕过。
项目以堆转储和 JVM 致命错误日志作为典型案例。这类诊断数据可能在 JVM 内部写入时就包含敏感信息，而此时外部脱敏工具尚未介入。另一个相关案例是 JEP 536：JFR In-Process Data Redaction，它会在数据离开 JVM 进程之前，对命令行参数、环境变量以及系统属性进行脱敏处理。
JEP 536 计划随 JDK 27 一同发布，并预计于 2026 年 9 月正式提供，因此目前既未包含在 JDK 25 中，也未集成到当前版本的 Eliya。Eliya 团队引用这一提案说明，部分诊断数据的脱敏更适合在 JVM 内部完成。不过他们也表示，目前 Eliya 仍处于第一阶段，文中讨论的许多场景尚未全部实现。
根据产品页面介绍，Eliya 标准版本直接跟随上游 openjdk/jdk25u，保持 Java API、标准库行为、JIT 编译、类加载机制以及模块系统语义与上游一致。页面还指出，上游 OpenJDK 25 已通过 Java SE 25 TCK 认证，而 Eliya 将在第二阶段完成独立的 TCK 验证。
此外，标准版本中的 java.security 文件与上游 JDK 25 完全一致，可直接通过 diff 工具进行比对验证。面向 FIPS 合规要求的版本将作为第二阶段推出的独立发行版提供，而不是标准版本中的一个可切换选项。
项目承诺，在每次上游 OpenJDK 发布季度关键补丁更新（CPU）后的两周内同步发布更新，并计划在一周内修复严重 CVE 漏洞。
Eliya 采用与 OpenJDK 相同的 GPLv2 + Classpath Exception 许可证，并将在 JDK 25 LTS 生命周期内持续提供支持，预计维护至 2029 年 9 月。在 Eliya 25 退役之前，还将与未来的 JDK 29 LTS 保持约 24 个月的支持重叠期。
目前，产品页面已经提供适用于多种处理器架构的 Docker 镜像，以及 tar.gz、DEB 和 RPM 安装包，均可通过 GitHub Releases 下载。官方计划于 2026 年第四季度上线托管的 apt/yum 软件仓库。
根据路线图，第二阶段预计于 2026 年下半年推出，届时将新增内置诊断工具、FIPS 版本、软件包仓库、持续 JFR 录制、统一 GC 日志以及更完善的 CLI 支持。后续阶段还计划推出 JVM 诊断取证平台，以及面向受监管行业、按需启用的合规配置。
InfoQ 就 Eliya 的设计初衷、策略边界以及迁移方式采访了 Asymm Systems 首席架构师 Fahim Farook。
InfoQ：什么时候启动脚本（Wrapper Script）和 Java Agent 已经无法满足需求？
Fahim Farook： 大多数情况下，启动脚本和 Java Agent 已经足够，我们也始终认为，大部分运维控制应放在 JVM 之外。真正的例外是，外部工具只能在 JVM 已经执行完操作之后才能看到结果。例如，堆转储和致命错误日志是在 JVM 内部直接生成的，等后处理工具介入时，敏感数据已经写入磁盘。我经常引用 JEP 536 作为例子，它说明在 JVM 进程内部完成数据脱敏，有时比事后清理更加合理。不过，这只能证明某一类运行时策略适合放在 JVM 内部，并不能代表 Eliya 整个路线图中的所有规划。
InfoQ：团队应该如何判断一项策略应部署在 Kubernetes、平台工具还是 JVM 中？
Farook： 我们采用的是分层设计。跨进程的能力应该交给 Kubernetes 或服务网格；进程级默认配置适合放在启动脚本或平台默认配置中；只有满足“可达性”或“不可覆盖性”条件时，才考虑修改 JVM。
Eliya 还区分了运维方（Operator）拥有的策略和监管方（Regulator）拥有的策略。像目前的生产配置属于运维方策略，因此仍允许用户按照 JVM 的优先级规则，通过命令行参数进行覆盖。而未来面向合规要求的配置则会采用“默认拒绝（Fail Closed）”原则，一旦运行时配置违反外部监管要求，系统将直接拒绝启动。
InfoQ：从其他 OpenJDK 发行版迁移到 Eliya 后，Java 团队需要面对哪些实际变化？
Farook： 对开发人员来说，变化应该非常小。Eliya 不会引入新的语言特性、应用 API，也无需修改构建流程或迁移现有框架。运维团队则需要重点评估生产配置带来的默认行为变化，例如诊断文件路径以及 OOM 处理方式，并判断使用一个统一的配置参数，是否比长期维护一套自定义 JVM 参数列表更加合适。对于企业用户，我们建议持续关注 Eliya 独立 TCK 验证的进展，因为这一工作将在第二阶段完成。
总体来看，Eliya 更适合那些需要规范化本地取证数据、可审计运行时环境或面向合规要求诊断能力的 Java 团队。而对于已经使用现有 OpenJDK 发行版，并依赖外部平台完成运维控制的团队来说，当前版本带来的收益可能相对有限，因为目前的生产配置主要是对现有 HotSpot 能力进行了统一封装，并没有引入新的 Java 应用层功能。
查看原文：Eliya 25 Brings a JVM-Level Diagnostic Profile to OpenJDK 25 LTS - InfoQ
