Integrations

Build tooling

Maven, Gradle, Ant, sbt, and other build tools work identically on Eliya; the JDK is invoked the same way and the modular runtime image is in the same location.

Maven Toolchains

Add Eliya to ~/.m2/toolchains.xml without modification:

Gradle toolchain auto-provisioning

Gradle's JVM toolchain auto-provisioning resolves Eliya via SDKMAN! (once registration completes, PR #783; until then, point Gradle at the JAVA_HOME path where you installed Eliya manually). The standard java.toolchain block works without Eliya-specific syntax.

Paketo Buildpacks (Spring Boot)

Paketo's default Java buildpack uses Liberica. To swap to Eliya, set the BP_JVM_VERSION environment variable to a version selector that includes Eliya's vendor string, or use a custom buildpack. A first-class Paketo Eliya buildpack is a Phase 2 consideration; signal demand on the downloads waitlist.

Container orchestration

Kubernetes

Eliya's Docker images are multi-arch OCI artifacts on GitHub Container Registry (ghcr.io/asymmsystems/eliya-jdk:25-lts and ghcr.io/asymmsystems/eliya-jdk:25.0.3). Standard Kubernetes deployment manifests work without modification. Two Kubernetes-specific patterns:

• Per-replica diagnostic paths. Eliya's three-level path layout (${ELIYA_DIAGNOSTIC_PATH}/${service}/${replica}/${category}/) maps cleanly to pod identity: set ELIYA_SERVICE_NAME via env to your service name; HOSTNAME (the pod name) auto-resolves as the replica. For explicit control, set ELIYA_REPLICA_NAME via the downward API.
• Ephemeral diagnostic containers. kubectl debug --image=ghcr.io/asymmsystems/eliya-jdk:25-lts --target=app attaches a full Eliya runtime to a running pod for incident-driven JFR/heap-dump investigation. Requires Kubernetes 1.23+ (stable in 1.25). See the Docker install guide for the full pattern.

OpenShift

Eliya runs identically on OpenShift. The standard pattern is the same as Kubernetes; the Phase 2 Red Hat UBI variant of Eliya (demand-gated) addresses OpenShift's preference for UBI-based images. Signal demand on the downloads waitlist.

Docker Compose

For local development, the standard pattern is to mount a host path as ${ELIYA_DIAGNOSTIC_PATH} so diagnostic artifacts survive container restarts:

Logging stack integration

Eliya's diagnostic path layout is designed to work cleanly with standard log-collection tooling. The flat per-replica directory structure means tools that walk paths see exactly what they expect:

• logrotate: GC log files (gc/gc-*-*.log) are pre-sized and rotated by Eliya's own configuration; logrotate can additionally archive older rotations off the per-replica directory.
• fluentd / fluent-bit: tail GC log paths and parse via the standard unified-logging format. JFR recordings should be shipped as files, not tailed.
• vector: file-source on /var/log/eliya/**/gc/*.log works directly. JFR recordings should be handled by an explicit ship-on-rotation pattern.
• journald: for systemd-managed services, JVM stdout/stderr flows to journald normally; Eliya's diagnostic artifacts live on the filesystem alongside.
• Audit-pipeline tooling: the per-replica directory structure preserves chain of custody from incident to artifact to producing replica without requiring correlation with external systems. Each subdirectory's name identifies the specific pod, container, or systemd unit that produced its contents.

Path layout reference: flags reference: diagnostic paths.

Service mesh diagnostics

For Istio, Linkerd, Consul Connect, or other sidecar-based meshes, two patterns apply:

• Always-on diagnostic sidecar. Run an Eliya container alongside the app container, sharing the diagnostic volume. Lower friction for scheduled tasks (periodic heap dumps, JFR rotation) but pays ~40 MB memory for the idle JVM (plus container base-image overhead) and negligible CPU per pod for an idle sidecar.
• Ephemeral debug containers. Recommended for incident-driven diagnostics on Kubernetes 1.23+. Zero baseline cost; injected on demand via kubectl debug. See the Docker install guide.

Sidecar JFR investigation works regardless of mesh choice: the mesh handles application traffic; Eliya handles JVM diagnostics. The two don't conflict.

CI/CD pipelines

GitHub Actions

Use actions/setup-java with distribution: 'jdkfile' pointing at an Eliya tar.gz from GitHub Releases. SDKman-based actions/setup-java with distribution: 'eliya' ships once SDKman registration is live.

Jenkins

Configure Eliya as a Tool in Manage Jenkins → Tools → JDK installations. Use the tar.gz URL or the Eliya install on the Jenkins agent.

ArgoCD / Flux

GitOps deployment patterns reference Eliya container images via the standard image: field. The ghcr.io/asymmsystems/eliya-jdk:25-lts moving tag works for "latest CPU"; ghcr.io/asymmsystems/eliya-jdk:25.0.3 pins a specific version; see the lifecycle page for pinning patterns.

APM coexistence

Eliya coexists with APM agents (AppDynamics, Dynatrace, New Relic, Elastic APM, Datadog APM) using the standard -javaagent: mechanism. The two are complementary: APM identifies when something happened; JFR identifies what the JVM was doing during that period.

Two coexistence issues to watch for:

• JFR conflict with Datadog Continuous Profiler or similar. Some APM tools also start JFR recordings. If both Eliya and an APM agent try to start recordings, the second fails with Recording already in progress. Resolution: let one manage JFR, or coordinate with the vendor for shared recording access.
• Combined memory overhead. Eliya adds ~13–26 MB. APM agent overhead varies by vendor: AppDynamics documents ~10–100 MBiAppDynamics Java agent docs cite ~10-100 MB plus ~100 MB heap., Dynatrace budgets ~200 MBiDynatrace OneAgent requirements budget ~200 MB.; New Relic, Elastic APM, and Datadog publish no specific figure. On containers with tight memory limits, measure combined footprint before committing.

For the architectural story (what APM is structurally good at, what JVM forensics adds that APM cannot), see JVM forensics vs APM.

Cryptographic providers

Eliya inherits upstream OpenJDK 25's security providers unchanged (SunJCE primary). Common third-party providers integrate via the standard java.security mechanism:

• Amazon Corretto Crypto Provider (ACCP): add as an explicit Maven/Gradle dependency on any JDK including Eliya; works without runtime modification.
• Bouncy Castle (non-FIPS): standard provider registration via java.security or programmatic Security.addProvider().
• Bouncy Castle FIPS: will ship preinstalled in the Phase 2 eliya-jdk-fips variant; for Phase 1 use, add as a dependency and configure java.security for FIPS-mode operation.

FIPS-validated cryptography in Phase 1 requires manual provider configuration. The Phase 2 FIPS variant simplifies this with a preconfigured distribution; sign up for notification.

Application framework defaults

• Spring Boot: works identically on Eliya. For Spring Boot with Paketo Buildpacks, see the Build tooling section above.
• Quarkus: native-image builds use Red Hat Mandrel rather than any standard JDK; Eliya is not a Mandrel replacement. For Quarkus in JVM mode, Eliya works without modification.
• Apache Kafka, Cassandra, Elasticsearch, Solr: all run on Eliya without modification. Elasticsearch's bundled JDK recommendation stands; if you swap to Eliya, Elastic may not support the swap.
• Build tools as runtime targets (Maven, Gradle, Jenkins): Eliya works as the JDK powering these tools themselves, in addition to building artifacts.