Uninstall

Before you uninstall: diagnostic data

Eliya's EliyaProfile=Production writes diagnostic artifacts (JFR recordings, heap dumps, GC logs, crash logs) to /var/log/eliya/ by default. For compliance-conscious deployments this data may be regulatory evidence that must be retained beyond the JDK's lifetime.

Diagnostic data is NOT automatically removed during uninstall. The commands below remove the Eliya binaries; the diagnostic directory remains intact unless explicitly deleted.

If your environment requires retention of diagnostic artifacts for audit purposes, verify the data is preserved before uninstall and archive to long-term storage if needed:

If your environment requires explicit deletion as part of decommissioning (and retention requirements have already been met):

For environments operating under PCI DSS, HIPAA, SOX, or similar frameworks, consult your compliance team before deleting diagnostic data. Some frameworks require retention for 1–7 years depending on the artifact type.

SDKman (once registration is live)

SDKman integration is coming soon (vendor ID 25.0.3-eliya is reserved; registration is rolling out). When the install command works, the uninstall command will be:

tar.gz archive

Remove the extracted directory. If you registered it with update-alternatives, deregister first:

Also unset or edit any shell profile lines exporting JAVA_HOME that pointed at the Eliya install path. The asymm CLI lives at ${JAVA_HOME}/bin/asymm on tar.gz installs, so removing the install directory cleans it up automatically.

.deb package

Remove package files (configuration preserved):

Remove package files and configuration:

update-alternatives deregistration and the /usr/bin/asymm symlink removal happen automatically with either command. On purge (not remove), the eliya-diagnostics system group is also removed. Service accounts that were added to that group as part of Eliya integration are not modified; they remain members of a now-deleted group, which is harmless but worth noting if you audit group memberships post-uninstall.

.rpm package

Standard removal:

On RHEL / Fedora / CentOS with dependency cleanup:

update-alternatives deregistration and the /usr/bin/asymm symlink removal happen automatically. The eliya-diagnostics system group is removed by the postuninstall script; service accounts added to that group are not modified.

Docker

Stop and remove containers using the image first; docker rmi fails if running containers reference it:

Then remove the image:

Note on diagnostic volumes. If you used the sidecar pattern or mounted /var/log/eliya as a volume, that volume is NOT removed by removing the image. Diagnostic data persists. Remove explicitly only if retention requirements have been met:

For Kubernetes deployments, the image cache on nodes is removed by the node's image garbage collection on its own schedule. To force removal across a cluster, follow your platform's image cleanup procedure.

After uninstall: application-side cleanup

Eliya's uninstall doesn't touch application-side configuration that references Eliya. Check for:

• systemd unit files referencing /opt/java-25.0.3-eliya/bin/java
• JAVA_HOME exports in shell profiles, application startup scripts, CI/CD configuration
• Maven Toolchain definitions referencing Eliya
• Application configuration files referencing diagnostic paths
• Environment files (e.g., /etc/default/<service>) setting ELIYA_SERVICE_NAME or ELIYA_REPLICA_NAME

Update these references to point to the replacement JDK before restarting services.

Uninstall scenarios

If you're switching to a different OpenJDK distribution (Corretto, Temurin, Zulu, etc.), uninstall is reversible; your applications run on the replacement JDK without code changes since Eliya is built from the same upstream source.

If you're rolling back the Eliya adoption decision entirely (returning to your previous JDK), this is the same procedure as the migration in reverse; see Migration guide: Rollback.

Either way, application code and data are unaffected. Eliya is a runtime; uninstall is a runtime swap.

Future considerations

Phase 2 will add bundled diagnostic tooling (Eclipse MAT headless, async-profiler) and a FIPS-validated variant (eliya-jdk-fips package). Uninstall procedures for these ship with the corresponding variant.

Phase 4 compliance profile activation may create additional diagnostic artifacts. Operators uninstalling a Phase 4 Eliya in compliance-active deployments should consult the compliance-profile documentation for any framework-specific retention requirements.