Asymm Systems has released Eliya 25.0.3, an OpenJDK 25 LTS distribution that introduces a JVM-level policy point for production diagnostics via the opt-in flag -XX:EliyaProfile=Production. Available since June 2026, Eliya is designed for Java teams that require reliable crash, memory, and runtime diagnostics from production workloads, particularly in regulated environments where diagnostic artifacts may be used in audits or incident analysis. Eliya is presented as a conservative OpenJDK distribution, not as a new Java framework, language extension, or application API.
The current Production profile consolidates several existing HotSpot features under a single control. It configures heap dumps on out-of-memory errors to structured per-service paths, enables exit-on-OOM for clean orchestration restarts, sets Native Memory Tracking to summary mode, ensures predictable hs_err crash log locations, and unlocks diagnostic VM options required for JFR sampling and profiler attachment. The profile also maintains container support, which is already enabled by default in JDK 25, to ensure future compatibility.
In a Foojay article introducing Eliya, Fahim Farook, Principal Architect, Asymm Systems, explains that Phase 1 does not introduce any runtime behavior that cannot be achieved with existing JVM flags. The main value of EliyaProfile in this release is to establish a policy point within the runtime for future capabilities that may require VM changes.
Eliya’s design is based on the principle that most production policies should remain outside the JVM. Service authentication, network controls, scheduling, secrets injection, resource limits, heap sizing, and GC choices are best managed by Kubernetes, service meshes, admission controllers, wrapper scripts, or platform defaults. The project considers JVM-level policy appropriate only when either of two conditions apply: "reach," where behavior has no useful external interface, or "non-overridability," where behavior can be externally accessed but later changed or bypassed within the runtime.
The project cites heap dumps and fatal-error logs as examples where sensitive data may be written by JVM internals before external sanitizers can act. A related example is JEP 536, JFR In-Process Data Redaction, which redacts command-line arguments, environment variables, and system properties before this data leaves the process. JEP 536 is planned for JDK 27, with general availability in September 2026, and is not included in JDK 25 or the current Eliya release. The Eliya team cites this to support the view that some diagnostic redaction is best handled in-process, while noting that Eliya is still in Phase 1 and that not all discussed scenarios have been implemented yet.
According to the product page, Eliya's standard build follows upstream openjdk/jdk25u and maintains Java APIs, standard library behavior, JIT behavior, class loading, and module-system semantics. The page also notes that the upstream OpenJDK 25 source passes the Java SE 25 TCK, and an independent TCK run of the Eliya binary is planned for Phase 2. Additionally, java.security in the standard build is bit-identical to upstream JDK 25 and can be verified with diff. A FIPS variant is planned as a separate Phase 2 artifact, not as a toggle in the standard build.
The project commits to quarterly Critical Patch Updates within 2 weeks of each upstream OpenJDK release and aims to address critical CVEs within 1 week. Eliya is distributed under GPLv2 with Classpath Exception, matching the upstream OpenJDK license. Support continues through the JDK 25 LTS window until September 2029, with a planned 24-month overlap with JDK 29 LTS before Eliya 25 is retired.
The product page currently offers multi-arch Docker images, tar.gz, DEB, and RPM downloads from GitHub Releases, with hosted apt/yum package repositories planned for Q4 2026. The roadmap schedules Phase 2 for the second half of 2026, which will include bundled diagnostic tools, a FIPS variant, package repositories, continuous JFR recording, unified GC logging, and expanded CLI support. Future phases will introduce a JVM diagnostic forensics platform and demand-driven compliance profiles for regulated sectors.
InfoQ engaged with Fahim Farook, Principal Architect at Asymm Systems, about Eliya’s motivation, policy boundaries, and migration paths.
InfoQ: When do wrapper scripts and Java agents stop being enough?
Fahim: In most cases, wrapper scripts and Java agents are sufficient, and the project maintains that most operational controls should remain in external layers. The exception is when an external tool can only observe results after the JVM has acted. For example, heap-dump and fatal-error-log writers produce data before post-processing tools can intervene. I often point to JEP 536 as evidence that in-process redaction can be preferable to post-hoc scrubbing; however, this supports only a specific class of runtime-placement arguments, not the entire Eliya roadmap.
InfoQ: How should teams decide whether a policy belongs in Kubernetes, platform tooling, or the JVM?
Fahim: The team follows a layered approach. Cross-process concerns should be managed in Kubernetes or service meshes, while process-specific defaults belong in wrappers or opinionated defaults. VM patches are reserved for cases that meet the reach or non-overridability criteria. Eliya distinguishes between operator-owned and regulator-owned policies. Operator-owned profiles, like the current Production profile, allow explicit command-line overrides under standard JVM precedence. Future compliance profiles are designed to fail closed if a runtime configuration would violate an externally owned constraint.
InfoQ: What practical changes should Java teams expect when moving from another OpenJDK distribution?
Fahim: For developers, the intended change is minimal: there are no new language features, application APIs, build changes, or required framework migrations. Operations teams should review the profile's default changes, especially diagnostic paths and OOM behavior, and determine if the single profile flag is preferable to maintaining a custom JVM flag list. The team advises enterprise users to monitor the independent TCK verification status, as this is scheduled for Phase 2.
Eliya is most relevant for Java teams that require structured local forensic data, an auditable runtime posture, or compliance-focused diagnostic controls. Teams satisfied with existing OpenJDK distributions and external platform enforcement may see less immediate benefit, as the current Production profile primarily selects existing HotSpot behavior rather than introducing new application-facing Java features.