JNI and JVMCI backends

Choose a backend

JNI remains the default for existing Profiles and configurations. It packages native libraries for the selected release targets. JVMCI installs compiled code into a supported HotSpot runtime and produces one target-specific JAR per build. Choosing JVMCI does not make the artifact portable across arbitrary Java distributions or versions.

The backend selector preserves a separate editing draft for each backend. Review the available modules and any configuration adjustments before requesting a quote. The build records the effective backend, target, and configuration so that its history describes what was actually compiled.

JVMCI targets and runtime

JVMCI supports one explicit target per build: windows-x86_64 or linux-x86_64. The Linux compilation service can produce either target; cross-compilation does not combine them into a universal JAR. JNI retains its multiple-target workflow.

The supported JVMCI runtime is Azul Zulu 22.0.2+9, x86-64 with G1 and the required runtime flags. Download the artifact and copy the target-specific launch command from the build details. Preserve its flags and use the stated runtime, rather than substituting the Java executable currently on your path. The artifact verifies its runtime profile when it installs code.

Linux JVMCI artifacts also require the system OpenSSL libcrypto library for native artifact binding, even when optional protection features are off. The compiler release includes jvmci-package-verification.json, which records the actual shared-library names required by its packaged Linux bridge. Install matching runtime libraries on the application host; the JDK alone does not supply them.

For local CLI builds, choose --backend jvmci --compile-for windows-x86_64 --lto off, or use linux-x86_64 for a Linux artifact. Omitting the target keeps the CLI's host default. Use the launch command emitted for the chosen target. Test the exact resulting JAR on that target before distributing it.

Modules and presets

JVMCI has its own versions of the five build presets. LTO supports off, Thin and Full; IR optimization is required, and dynamic registration is built in. For JVMCI, enabled LTO optimizes each method recipe’s complete native link unit. It preserves JVM call boundaries and does not inline Java methods across recipes. JNI-specific Unsafe, VMBridge, static direct-call, and virtual inline-cache controls do not apply. The module catalog explains support and dependencies for the selected backend and target; a JNI preset cannot simply be relabeled JVMCI.

Runtime protection also depends on the target. A feature available on Windows is not automatically available on Linux. Unsupported combinations are reported before compilation; selecting a different target does not silently provide equivalent protection.

Semantic Mirage is an experimental JVMCI option. Runtime Profile is an opt-in diagnostic feature and adds measurement work; leave it off in ordinary production builds unless those counters are required. Structural Obfuscation has an application mode and an experimental whole-artifact mode. Its private mapping is available with the build artifacts and should be retained with the corresponding release.

Configuration and billing

Web YAML import and export include the backend, target, and module configuration. They use the Web preset format, not arbitrary CLI JSON. Existing configurations without a backend continue to select JNI.

JVMCI builds use the existing NCU calculation with the effective selected methods, single target, selected LTO mode, and enabled features. The independent NOL configuration analysis is free and does not reserve or spend NCU. A successful compilation is not a performance guarantee: test behavior and measure the workloads that matter to your application.