OpenJDK for government and public sector JVM

One requirement an external wrapper cannot meet

Two examples sit outside what any external selector can do. ISO 27001 control A.8.15 expects logs to be produced and protected, including the artefacts a process writes while it is crashing, by crash-path code only the VM runs. And change-control attestation wants proof that the running configuration is the approved one, but a flag's origin, whether a profile set it or someone's command line did, is internal VM state, invisible to any external tool. Both live in the capability space, and they are two of several such requirements; the policy point essay sets out the general case, here applied to public-sector assurance.

What Eliya gives a public-sector workload today

One flag, -XX:EliyaProfile=Production, activates the Phase 1 operational-readiness defaults: heap dump on OutOfMemoryError to a structured path, a predictable crash-log path that does not die with the container, Native Memory Tracking (summary), reinforced container support, and exit on OutOfMemoryError. Diagnostic data stays on government-controlled infrastructure: no SaaS, no telemetry, supporting data sovereignty and air-gapped deployments.

Eliya is built reproducibly and signed (Ed25519); you verify the published artefact against the SHA-256 checksums and the detached GPG signature before trusting it. It is GPLv2 with the Classpath Exception, on a quarterly LTS Critical Patch Update cadence.

What does not ship today

Eliya is not FedRAMP authorised, and it does not ship a government compliance profile today. What it ships is the policy point, protected crash-path diagnostics, reproducible signed builds, and local-only capture. A FIPS 140-3 variant is a Phase 2 deliverable; compliance-aligned profile values are demand-gated and sit in Phase 4. Neither is in the 25.0.3 binary; the roadmap sets out the trajectory.

Next: download Eliya, read the thesis, or verify your download.