Differences from upstream OpenJDK 25

Behavioural differences when no flags are set

None. Without -XX:EliyaProfile=Production on the command line, Eliya 25 behaves identically to upstream OpenJDK 25. This is deliberate; users who want vanilla behaviour get vanilla behaviour.

Behavioural differences when -XX:EliyaProfile=Production is set

This flag uses enum-value syntax. It is a Layer 2 profile that activates the production-readiness defaults documented below. Future Eliya versions will carve out the underlying Layer 1 capability flags (UseEliyaObservability, UseEliyaDiagnostics, etc.) for users who want finer-grained control via EliyaProfile=None plus selected boolean capabilities. See flag architecture for the full taxonomy.

Phase 1 today (25.0.3): six ergonomics activated by -XX:EliyaProfile=Production. None are upstream defaults.

1. Heap dump on OOM: -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${ELIYA_DIAGNOSTIC_PATH}/${service_name}/${replica_name}/heap/
2. Exit on OOM: -XX:+ExitOnOutOfMemoryError
3. Native Memory Tracking: -XX:NativeMemoryTracking=summary
4. Crash log path: -XX:ErrorFile=${ELIYA_DIAGNOSTIC_PATH}/${service_name}/${replica_name}/crash/hs_err_pid%p.log
5. Container support reinforced: -XX:+UseContainerSupport (already upstream default; reinforced for clarity)
6. Diagnostic VM options unlocked: -XX:+UnlockDiagnosticVMOptions -XX:+DebugNonSafepoints, required for accurate JFR and async-profiler sampling, and makes them usable today via one-flag activation (-XX:StartFlightRecording=…)
7. Conflict detection: EliyaConflictCheck is enabled by default. Startup-time inspection of the command line responds to conflicts between the profile-implied defaults and explicit user flags in three tiers: silent override (user explicit wins), warning (redundant flag), fatal (incompatible combination). See flag architecture: conflict detection.

Phase 2 (planned): two additional ergonomics activated by the same flag once the bundled diagnostic tools work lands:

1. JFR continuous recording (Phase 2): -XX:StartFlightRecording=settings=default,disk=true,maxage=24h,maxsize=250m,dumponexit=true,filename=${ELIYA_DIAGNOSTIC_PATH}/${service_name}/${replica_name}/jfr/recording.jfr
2. Unified GC logging (Phase 2): -Xlog:gc*=info:file=${ELIYA_DIAGNOSTIC_PATH}/${service_name}/${replica_name}/gc/gc-%t-%p.log:time,level,tags:filecount=10,filesize=100M

The ${replica_name} level is suppressed when it resolves to the same value as ${service_name} (bare-metal multi-JVM hosts, or all-fallback cases). See flags reference: diagnostic paths for the full resolution algorithm and effective path examples across deployment topologies.

All eight observability changes are diagnostic; none change GC selection, GC tuning, JIT behaviour, or runtime semantics.

Patch-level differences in the Eliya binary

These are present in the binary regardless of command-line flags.

1. Product flags added: two new flag declarations in src/hotspot/share/runtime/globals.hpp:
   • EliyaProfile (ccstr, product flag, default value None; Phase 1 range {None, Production}; Phase 4 expands the enum)
   • EliyaConflictCheck (bool, product flag, default true; controls startup-time conflict detection)
2. Argument resolution helpers: three new functions in arguments.cpp:
   • resolve_eliya_base_path(): resolves ELIYA_DIAGNOSTIC_PATH env → platform default (Linux: /var/log/eliya).
   • resolve_eliya_service_name(): resolves ELIYA_SERVICE_NAME env → eliya.service.name sysprop → HOSTNAME → literal default.
   • resolve_eliya_replica_name(): resolves ELIYA_REPLICA_NAME env → eliya.replica.name sysprop → HOSTNAME → suppressed when equal to service.
3. Path builder helpers: build_eliya_path(category) and build_eliya_error_file_path() in arguments.cpp. Both implement the replica suppression rule (collapse to two-level path when replica equals service).
4. Profile activation: apply_eliya_production_profile() in arguments.cpp sets the observability options above when EliyaProfile=Production is parsed, respecting FLAG_IS_CMDLINE semantics so explicit user flags always win.

Packaging differences

1. /var/log/eliya/ base directory created by RPM/DEB postinstall with eliya-diagnostics group and g+w permissions. The deeper path components (/var/log/eliya/${service_name}/${replica_name}/${category}/) are created on demand by the JVM when JFR / heap dump / GC log / crash log first writes, inheriting the eliya-diagnostics group from the base directory.
2. asymm CLI installed at /usr/bin/asymm (Phase 1 surface: --info, --version, --help; the asymm eliya … subcommands are reserved for Phase 2)
3. No bundled diagnostic tools in Phase 1. Phase 2 will bundle Eclipse MAT (headless) and async-profiler

What is NOT different from upstream

Eliya is conservative about what it changes. The following are upstream OpenJDK 25 defaults that Eliya does not modify:

• GC selection (G1 default per JVM ergonomics, ZGC / Shenandoah / Parallel / Serial available)
• JIT compiler tier transitions
• Class loader behaviour
• Module system configuration
• Security provider order: SunJCE remains default; FIPS variant is a separate artifact (Phase 2)
• TLS protocol defaults: already secure in upstream JDK 25 (SSLv3 / TLS 1.0 / TLS 1.1 disabled)
• Cipher suite preferences: already secure in upstream JDK 25 (RC4 / DES / 3DES / MD5 blocked)
• All algorithm-disabling lists in java.security: already configured in upstream JDK 25

Eliya does not claim a "TLS hardening overlay" or "additional security defaults" because upstream JDK 25's defaults are already correct. Re-declaring upstream work as an Eliya feature would add nothing.

Verify java.security is unchanged:

The command produces no output; the files are byte-identical to upstream OpenJDK 25.

Roadmap differences (Phase 2 + Phase 4 planned)

Items planned for later phases that will add to this diff:

1. FIPS-validated variant build (eliya-25-fips.tar.gz, Phase 2): separate artifact with a FIPS-validated provider pre-installed and registered. Standard eliya-25.tar.gz continues with SunJCE. Provider choice (Bouncy Castle FIPS or alternative) is locked when the variant ships.
2. Bundled diagnostic tooling (Phase 2): Eclipse MAT (headless, EPL 2.0) and async-profiler (Apache 2.0) bundled at ${JAVA_HOME}/lib/.
3. asymm eliya CLI Phase 2 subcommands: wrappers around bundled tools and jcmd operations.
4. TCK conformance (Phase 2): runs the Java SE 25 TCK against the Eliya binary itself under the OpenJDK Community TCK License Agreement (OCTLA). Phase 1 binaries are built from upstream OpenJDK 25 source (which passes the TCK). TCK conformance is a property of a specific built binary, not of the source: the Phase 2 run establishes the Eliya binary's own conformance.
5. Layer 1 capability flag carve-out (Phase 2): seven new capability flags in globals.hpp: UseEliyaObservability, UseEliyaDiagnostics, UseEliyaOperational, UseEliyaTooling, UseEliyaSecurityBaseline, UseEliyaSecurityStrict, UseEliyaAudit. Engineers wanting finer-grained control will set EliyaProfile=None and compose capabilities directly.
6. Layer 2 profile expansion (Phase 4): the EliyaProfile enum expands with single-framework values (PCIDSS, HIPAA, SOX, FedRAMP, GDPR, ISO27001, SOC2) and explicit combined profile values (e.g., Healthcare-Payment for PCI DSS + HIPAA). Combined profiles are designed explicitly, never stacked from single-framework values. See flag architecture for the trajectory.