Features, platforms, and method selection

The following multi-platform rules describe the default JNI backend. JVMCI produces one Windows or Linux x86-64 target per build and requires its supported Zulu runtime; see JNI and JVMCI backends. Native libraries are platform-specific. Request only the platforms your release supports, using canonical target names such as windows-x86_64, linux-x86_64, linux-aarch64, android-aarch64, macos-x86_64, and macos-aarch64. OS-only names expand to several targets, and hosted builds allow at most four distinct expanded targets. An explicit platforms request wins over a project default; absent both, the service falls back to linux-x86_64. Make the target list explicit in release automation instead of relying on that fallback.

For features, explicit features wins over processorId; otherwise an owned processor preset, project defaults, and finally disable-annotation-check are considered. Annotation selection gives the most control. @Nativify has class retention; static methods, instance methods, and constructors can be selected directly. Class initializers are selected through a class-level annotation or disable-annotation-check. Initializer bodies are protected through generated static native helpers because the JVM does not allow <init> or <clinit> themselves to be native. Abstract methods remain ineligible.

native-unsafe and native-llvm-direct-call are independent LLVM_CONFIG compiler features and may be enabled together. Their combination has been validated with the existing Java 8 workloads, not exhaustively across every JVM, platform, or input. Test the exact feature set and target-native behavior with representative workloads before release.

invokedynamic and lambdas are native-lowered with caller-correct bootstrap linkage and cached dynamic invokers. Multidimensional array creation can still require extraction, and some primitive-array cases remain unsupported. JNI crossings can add overhead, so validate both correctness and performance using representative workloads.